Would anyone be capable of making a barcode reader with vacuum tubes? - Page 1
Forum section: electronics / general

author: Connecteur
author_rank: Frequent Contributor
timestamp: November 14, 2021, 09:52:06 pm
content: Just a fun thought; I'd expect it to be a big challenge requiring a good deal of creativity, if possible.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 14, 2021, 10:37:32 pm
content: Yes.Why, how soon do you want it? And at what budget?(A challenge, yes; but I can't say I'm nearly enough intrigued to do it as a freebie. Nor from transistors or ICs, seeing as ready-made solutions including optics already exist and are very affordable.)Also, what would count as satisfactory, a 1-D barcode reader with serial output (the code that was read)? Or should it be fancier or do other things?2-D barcodes, like QR, are essentially impossible however; reliability versus the sheer number of devices required, makes this fairly intractable. You need a good bit more than an ENIAC to decode that.Tim

author: SL4P
author_rank: Super Contributor
timestamp: November 14, 2021, 11:04:49 pm
content: When I saw this, my mind immediately jumped to the old style pen/wand reader on a lead, pulled across the code by hand, but a laser scanning 1D reader would probably fall into the same category.Not easy, and certainly not small.

author: BrianHG
author_rank: Super Contributor
timestamp: November 15, 2021, 06:06:04 am
content: Watch this series. He is making an improved version of a MC14500B micro controller in vacuum tubes only using a +24 and -12v supply. There are 19 parts so far...https://www.youtube.be/playlist?list=PLnw98JPyObn0v-98gRV9PfzAQONTKxql3Going back further in time, here is is series on developing vacuum tube logic gates:https://www.youtube.be/playlist?list=PLnw98JPyObn057XAfTSPdvBrr86y62SnPWhy does EEVBlog show a single video now?It used to allow me to provide 'Playlist' links which you could click on and your browser would open a window with the complete playlist. Something went wrong.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 15, 2021, 08:21:30 am
content: Barcodes?The SR-71 used a optomechanical system to track stars and get worldwide positional navigation info.I don't think there are engineers alive today able to do something like this again.https://www.thedrive.com/the-war-zone/17207/sr-71s-r2-d2-could-be-the-key-to-winning-future-fights-in-gps-denied-environmentshttps://timeandnavigation.si.edu/multimedia-asset/nortronics-nas-14v2-astroinertial-navigation-systemhttps://airandspace.si.edu/webimages/collections/full/NAS-14V2%20ANS%20System.pdf

author: jonpaul
author_rank: Super Contributor
timestamp: November 15, 2021, 11:43:09 am
content: Beside the SR-71, Astro Nav optical tracking was used in ICBMs even in1968, I am sure the electronics as very early RTL logic in round metal cans.I recall this from my work at the time.Jon

author: jonpaul
author_rank: Super Contributor
timestamp: November 15, 2021, 11:47:32 am
content: Bonjour a tous, Perhaps a bit OT .....About the first flash ADC used in 1942 SIGSALY unbreakable speech scrambler system,Please see my February 2019 IEEE Spectrum articles about reverse engineering and reconstruction of this unique bit of history.https://spectrum.ieee.org/rebuilding-a-piece-of-the-first-digital-voice-scramblerhttps://spectrum.ieee.org/sigsaly-analogtodigital-converter-construction-and-debuggingI used original WWII Thyratrons 2051, and 6SL7 twin triode preamp for the microphone, also a time delay relay.Comments appreciated,Jon

author: SeanB
author_rank: Super Contributor
timestamp: November 15, 2021, 03:37:39 pm
content: Aircraft used mechanical computing units for a long while, that did quite a good job in providing navigation systems that ran off an inertial platform. I scavenged a good number of them as a source of spare parts for other aircraft, as it was hard otherwise to get them as spare parts. We had a big collection of those black boxes to use as spares, taking a new one when the old one was picked clean, and even there I was using the non useable ones, as a source of bearings to repair equipment fans. 115VAC 3 phase 400Hz fans are not too common, but used the same stator coil cores as a lot of synchro units, and the same bearings as well, so they were rebuilt.

author: rstofer
author_rank: Super Contributor
timestamp: November 15, 2021, 04:47:28 pm
content: Quote from: MasterTech on November 15, 2021, 08:21:30 amThe B-52 has a similar scheme.I don't see why an engineer today couldn't replicate a system that is still in use, every single day. The system is much more reliable that GPS (as a source) because the stars will be in the same location for a very long time relative to a single flight and probably can't be hacked.Every system is created from 'boxes' - some expression of a logical function. Implementing the 'box' is just a matter of cookie cutting circuits and hooking them together. Four tubes per D-flop pretty much limints my enthusiasm but if someone paid enough money, why not?I would probably start by building a mock-up in an FPGA. Once I had the logic worked out, it's a matter of transferring the VHDL to vacuum tube technology.And I don't know that the B-52 system isn't solid state. It could have been upgraded at some point. Next time I tour the air museum, I'll ask the Navigator - he shows up every year for open cockpit day.

author: PartialDischarge
author_rank: Super Contributor
timestamp: November 15, 2021, 05:16:17 pm
content: Quote from: rstofer on November 15, 2021, 04:47:28 pmQuote from: rstofer on November 15, 2021, 04:47:28 pmThat's the thing, replicate. Todays engineers cannot do anything without PCs and microcontrollers and FPGAs and Solidworks....The amount of work if that had to be done from 0 would be unsurmountable for todays heads. The level of 60s engineers was top-notch. Even the SR71, nothing better has been designed.If all the drawings and tools and calculations done back then were lost for this system, I don't think today graduates would tackle the problem easily.

author: Connecteur
author_rank: Frequent Contributor
timestamp: November 15, 2021, 06:44:24 pm
content: I'll echo the idea that many of the old skills are being forgotten, in favor of a digital solution. It's easier to break down the problem into bits (1s and zeroes) and then let a microprocessor handle it. But the real world isn't binary, and the skills engineers developed before the digital age should not be forgotten.

author: mag_therm
author_rank: Frequent Contributor
timestamp: November 15, 2021, 09:53:34 pm
content: Quote from: Connecteur on November 14, 2021, 09:52:06 pmYou could try an image orthocon with a close up lens.Into a VTR.I remember in 1972, one of the USA 'scope companies ( can't remember who) came out with a FFT for military use.That had a computer of the day. I don't know if there was ever a tube FFT recorder.So the best you might do would be to match signatures of a simple QR code.That would need about a kitchen and 2 bedrooms full of gear.

author: daqq
author_rank: Super Contributor
timestamp: November 15, 2021, 10:09:15 pm
content: Quote from: mag_therm on November 15, 2021, 09:53:34 pmThinking out loud here:For the QR code: An electro-mechanical-optical solution might actually be doable, if brute force. As an inspiration take a normal barcode scanner where you have a single beam of light being projected into dozens of lines by a simple rotating block of mirrors, each with a different reflection angle, being projected onto more mirrors. See *. Or take the single "pixel" thermal camera that scans an image using rotating mirrors. See **.Now how about a mechanism that continuously sweeps through different focuses, zooms and orientation on an optical system - basically a "brute force" approach. The optics concentrate the image onto an array of photoresistors or other photo sensitive devices. The evaluation electronics then "simply" look for the orientation markers on the sides.*:**:

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 15, 2021, 10:52:20 pm
content: Also, my tube cred, not that anyone doubtedhttps://imgur.com/gallery/OF4jAxhTim

author: TimFox
author_rank: Super Contributor
timestamp: November 15, 2021, 11:05:22 pm
content: Back in grad school in the dark 1970s, before FFT computation was routine, the electron microscope guys would do a 2D Fourier transform in a very analog way, but diffracting a laser beam through a transparency with appropriate glass optics.

author: rstofer
author_rank: Super Contributor
timestamp: November 16, 2021, 01:30:11 am
content: Quote from: T3sl4co1l on November 15, 2021, 10:52:20 pmAbsolutely outstanding!I remember when Numerical Control systems were based on relay logic. I spent quite a bit of time with a cross-bar PBX system (relay logic done large).

author: rstofer
author_rank: Super Contributor
timestamp: November 16, 2021, 01:53:31 am
content: Quote from: MasterTech on November 15, 2021, 05:16:17 pmI think the the ISS and Space Shuttles probably outrank the SR-71. We look back with admiration, realizing that it was designed with slide rules. Today it would be computer simulation. Is it better? Who knows! I sure wouldn't write off today's engineers. There's a fair bit of magic under construction.I'm a huge fan of the F106 - a single engine interceptor only 19 MPH slower than the twin engine F-14. I admire it for the simple reason that my father's fingerprints are all over them - back a long time ago. That, and it was introduced in '59 while the Tomcat came along in '74.The worst decision ever made was to install the MA-1 flight control system which allowed all the mothballed F106s to be used as remote controlled drones. What a waste! They belong in museums!https://www.f-106deltadart.com/flightcontrols.htmThe plane could even land without a pilot - the "Cornfield Bomber" - an interesting tale of lore:The old guys were good but I think the newer engineers are better because they know how to use more productive tools. They can also get the wrong answer to significantly more decimal places.

author: Berni
author_rank: Super Contributor
timestamp: November 16, 2021, 05:49:32 am
content: Bar code scanner is not really a problem with vaccum tubes since all it does is scan a laser across and wait for seeing a particular pattern in the light coming back. So you it just has to detect it, buffer it and then shift it out in serial at a fixed data rate.But when you get to QR codes you basically need a basic vacuum tube computer because the data is encoded with pretty complex error correction codes. Also finding the exact location and orientation of a QR code in a frame of video needs a fair bit of computation that can't be done by just running it trough a bit of logic. Tho if you simplify them down in to requiring the codes to be in a certain orientation and remove the complex encoding then it becomes much like a regular bar code scanner except that you might use a vidicon tube as a camera instead of a laser.Thing is that vaccum tubes can also be made into sort of "integrated circuits" by use of various tricks. So with some clever design you can make a decade counter, shift register, few bits of memory etc... into a single glass tube. They are not just simply FETs with pilot lights. Similar goes for electromechanical computation, there are not just relays that simply turn on and off. Instead its more along the lines of coils moving mechanical systems that can do much smarter things than just an AND gate. This is taken to even more of an advantage in those "analog mechanical computers" used to aim bomb drops, fly planes...etc where gear systems are used to directly calculate a mathematical function in real time, this not only does multiplication trough gear ratios but can produce also addition, subtraction, division, even integration. You still start off with the equation you want to calculate, but there must have been a LOT of manpower involved in designing and building it to turn it into the physical form, taking a team of skilled people months to do. But today the same functionality can be implemented by a single person in a single day using an Arduino.

author: Haenk
author_rank: Super Contributor
timestamp: November 16, 2021, 12:03:35 pm
content: Not that trivial: Barcodes usually use interleaved digit calculations plus checksum. You can do that by a matrix, but this will still require calculations, i.e. creating a computer from scratch.

author: Connecteur
author_rank: Frequent Contributor
timestamp: November 18, 2021, 05:23:20 pm
content: Quote from: Haenk on November 16, 2021, 12:03:35 pmI'm wondering if some genius couldn't come up with circuitry similar to the way TVs used to sync signals using only analog means.

author: LaserSteve
author_rank: Super Contributor
timestamp: November 18, 2021, 05:37:44 pm
content: Can I design my own tube? Can I design my own code? Can I have a HENE laser in the system?. Do you care about CRC?Depending on your answers, I can read a code very easily.While a prototype out of discrete tubes might be a nightmare, if I get to design a tube with 70s technology, no problem. CRC however would have to be done by someone far smarter then me.Depends on where I am sent, in 1970..If I'm in New Jersey it will be a computing ebeam tube with a optical Fourier transform as input.If I'm in Eindhoven expect something like custom decatrons as shift registers and memory with readout electrodes.If I have access to plastic light guides it gets even easier.Do I need to interface it to a Punched Card Machine?I'n fact. I'd be surprised that Phillips or RCA did not do something like this in the lab.Steve

author: coppercone2
author_rank: Super Contributor
timestamp: November 19, 2021, 09:02:29 pm
content: speaking of analog electro optical filters, try updating certain types of display as fast as possible. When I did it to a analog signal, it ended up working as a intensity filter. If you took the raw data to display at a reasonable rate it would give you tons of jumping. If you filtered it alot digitally it would give you 0.02, with the LSB flashing +-0.3 intermittantly (like interference, so you get 0.02 0.02 0.05 0.02 but most of the time you can read it to 0.01.When I got rid of the rate limiter so the LCD is updated as fast as possible, the display was also readable and stable at 0.02. Those 'spikes' that would make it jump occasionally were dimmed out by the display based on its persistence so much , that actually I thought that the optically filtered result was better then various digital filter implementations, it was smooth and responsive, so long you disregarded the jumpy ghost noise.So you analog filter digital display outputs to stabilize it rather then doing anything in code and the results were better in that system.You need a fadey display like a cheap oled or whatever, a seven segment or led will give bad results (you can't read a multi meter that's sampling too fast as much as a crappy display, oddly enough). i.e. 4x20 display from china is a good filter. you might also need to mess with the backlight to get it to display right and it might be dependent on display performance

author: cortex_m0
author_rank: Regular Contributor
timestamp: November 19, 2021, 11:58:58 pm
content: Quote from: LaserSteve on November 18, 2021, 05:37:44 pmRCA definitely had a "barcode" reader in the late 60s, although I wasn't able to determine if it used tubes or not. The RCA "barcodes" were round, so the term isn't quite appropriate. I would expect it was mostly or totally solid-state when deployed, but under wraps at RCA Labs, who knows.https://www.smithsonianmag.com/innovation/history-bar-code-180956704/Your point about being able to design your own code is a good one, because depending on what kind of detector you devised, changing the format of the barcode may be necessary.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 20, 2021, 04:30:13 am
content: Quote from: Connecteur on November 18, 2021, 05:23:20 pmI suspect you may vastly overestimate the complexity of analog television!The problem at hand is more akin to creating a multisync monitor. Whereas a TV can very safely assume its sweeps will be within a modest band around 15.7kHz and 60Hz, a more general device will have to monitor inputs, detect the frequency, or somehow adjust to it, and set its internal voltages, and whatever compensation adjustments need be made (S-correction capacitors, saturable inductors) to display an accurate picture. And indeed, this is what the actual units do, detecting the sync frequencies and using lookup tables to determine the correct settings, all in one or a few convenient ICs. Not necessarily that analog multisync is impossible, but man would it be hard to design, let alone adjust. They had it hard enough with color convergence/landing, a dozen controls (including adjustable resistors and inductors) that all interacted; plus the magnets on the CRT neck, and sometimes around the bulb too...Anyway, the fundamental problem is optical perspective. Depending on distance and orientation between label and scanner, the pattern will be read at any frequency over a wide range -- maybe say 10:1 or something. And the code doesn't last long enough to lock a PLL to it, it's not easy to track the signal.In comparison, NTSC colorburst was always at a reliable position during a line, with consistent frequency and phase; often instead of a full-on oscillator and PLL, they just injected the burst into a free-ringing crystal, and just let it ring down between lines. (Effectively treating the colorburst separator as a filter following a gated (tone-burst) waveform. Gated with a low duty cycle means, there's a peak at 3.58MHz, but it has a quite wide spectrum (having a sinc-like profile, built of 15.7kHz sidebands and etc. It takes a very sharp filter indeed, to pick out just the very peak of that spectrum. Fortunately, quartz crystals can deliver.)Getting the signal, by the way, isn't too bad -- if we allow lasers (hey, HeNe is a tube, right?), then we can just take a nicely collimated one and sweep it across the label. I don't think there's really much to gain with different codes -- the straight bar version is about as good as any. A circular pattern is rotationally symmetric, but if we're scanning linearly, what good is that except when perfectly across the axis? The straight-bar pattern is tolerant of view-axis (roll) rotation, and modestly tolerant of off-axis rotation (i.e., including a perspective transformation). Perspective is nonlinear, meaning the frequency of the texture varies along any line not parallel to the plane and viewing angle; we could deal with more oblique viewing angles by using longer codes (encode it with more timing information?) and larger ratios between mark and space symbols (for pulse codings).Anyway, just shining a laser wouldn't be quite enough, we would want to use a modulated beam -- this gives better discrimination against ambient noise, background light etc. Same principle as IR remotes, for example: use a carrier tone, then filter out just that, then do AGC, demodulation (can be synchronous, since we control the source too), and do thresholding and decoding on the demodulated signal. That's all normal stuff, radios have been doing that for a very long time indeed -- in fact, NTSC vertical sync is a case of this, where the H-sync pulses widen during vertical retrace, the pulse width being detected with an amp and filter as V-sync.So we get a sequence of bits, interspersed with random environmental noise or backscatter. Basically we can say it's a serial signal at some baud rate, but we don't know what that rate is. If we can mask out noise, it might be feasible to run a PLL from it, given a self-clocking code like Manchester (or generally whatever FM or MFM we might choose). After some number of scans, we can guess the PLL is probably locked on, and decode that -- say clocking a shift register at its rate, thus latching out a digital word corresponding to the code, plus whatever stray bits at either end get dragged along by the gating. (That we get a code at all, is mainly what matters; how many bits we waste in the register, is a matter of efficiency rather than utter possibility.)Oh, interesting aside, we could do analog levels as well. Doesn't really amount to much, it's gotta be decoded digitally somehow or another -- it's a code, not an image -- but it's interesting, and this idea had practical application, such as LaserDisc. (Which was notoriously sensitive to cleanliness, so, there's that, too.)PLL can work both ways, maybe we servo the mirror motor itself to give the same frequency of scanned code; that might be easier, or maybe it doesn't matter. (An RC relaxation oscillator can be used as VCO, about as easily as running a power amp into a DC motor.)And then actually decoding the captured data of however many bits, take your pick. Probably some rudimentary ALU and state machine, a computer stripped down to the barest hard-wired essentials. No idea how many tubes that might take, a hundred? Surely under a thousand. A serial machine would be nice (saves on bus drivers and gate arrays; shift registers are fairly cheap, especially with glow-lamp logic say), but might not be as practical as it sounds (using the signal directly would be nice -- it is its own memory -- but you're only scanning the codewhile you're scanning it, and then it goes away; you still need a register to hold onto results).The digital solution, in contrast, might not even bother with the PLL, but just clock at a much higher sampling rate, so take down maybe a thousand bits instead, then figure out how many adjacent bins of 1s/0s correspond to each code, and scan and convert the array into the actual code. And obviously, with a proper ([memory-constrained] Turing complete) CPU, it's just a matter of writing the firmware, then waiting for the conversion; it might take 10k's of CPU cycles, but that's fine, at 1MHz+ it's still done faster than you can blink. But it's a lot harder to do that with when every bit of storage and every gate of logic costs multiple whole tubes!Tim

author: Someone
author_rank: Super Contributor
timestamp: November 20, 2021, 06:09:38 am
content: Quote from: T3sl4co1l on November 20, 2021, 04:30:13 amYou're possibly jumping to the same digital calculation blinkers that people are discussing above. Given tube era technology, leave as much of the processing in analog as possible! Delay lines (liquid metal, ultrasonic, etc) for "memory", then plenty of optical and frequency domain processing. Avoid digital wherever possible.Get a solid checksum/verification solution/design, and spam random orientation and scale until something falls through the sieve.

author: Psi
author_rank: Super Contributor
timestamp: November 20, 2021, 06:37:23 am
content: You could make a 386 CPU out of vacuum tubes and play doom, but at 100khz clock it would take at least 40 seconds to render 1 frame and consume 1.5MW of power. (colossus was 1500 tubes and 8kW and a 386 is 275,000 transistors).

author: T3sl4co1l
author_rank: Super Contributor
timestamp: November 20, 2021, 07:04:19 am
content: Quote from: Someone on November 20, 2021, 06:09:38 amYes -- if the requirement is electronic rather than electromechanical, and largely off the shelf (heh, for as many tubes as you can find on the shelf, anyways), it might be something like I said. Granted, I'd allow delay lines and optical masks, to the extent you're willing to make them. Though I'm not sure what you can do with them exactly. (Obviously, delay lines let you multiply the stored bits/tube, but you still need to get the bits in and out of 'em.) One of the differences with not being familiar with that technology!Optical masks, I wonder if a shift register for converting time to space would do (can include any sort of raster scan, like a CRT), then using perspective transforms (aha!) to shift the spacial frequency, then vary the scale factor (distance between scanner and projector) until it picks up the clock frequency (by tuned circuit). Would be neat to use Doppler to do rate conversion but I'm not sure what you'd use for a medium. Oh, or heck, just short all that out, I wonder if that can be done by adjusting the optics themselves (e.g. zoom lens). Or even less complicated still, maybe the laser beam can be projected parallel, rather than swept-angle so the scanned frequency is only sensitive to relative angle and parallax. Yeah, and then instead of a prismatic mirror it could be tapered or something, and the scale done by scanning along that in turn.Scanning one variable-geometry parameter, while also scanning the barcode itself, is kind of dubious in terms of missing combinations (if harmonically locked, they trace a certain regular path), or warping caused by combined relative motion (particularly at low ratios of scan rate), or requiring massive scan rates (like a TV raster -- mechanical TV isn't exactly practical). If they're not harmonically locked, they'll eventually hit most combinations, and like you say, a good verifier only needs it to work once.Oh, and hey, a lot of algorithms effectively throw away partial results in the course of a search; instead of wasted computation, why not just throw away useless input instead?Another thing we take for granted, being able to compute a whole load of stuff at once; like the difference between mechanical scanned (samples each location only very briefly) vs. vidicon TV (continuous optical integration), however in this case we have very little limitation imposed by intensity / SNR so can afford to make exactly such a trade in the opposite direction. Or of FFT vs. sweep in spectrum analysers.Or you just don't care about perspective/rotation, and stipulate that the scanner has to be held near a particular distance and angle, and it just doesn't recognize a scan for higher frequencies (distances). That's honestly not too useless, I mean everyone already has the experience that scanners can be picky. Maybe emboss the design a bit, so the scan head kinda keys into it, that wouldn't be expensive to do with cardboard cartons, or attach suitably shaped placards to wood/metal/etc.Tim