Re: Curved CRTs?


Adding detail never made a sailor's tale more believable.
I call photo or it didn't happen.
If that makes me a bad person, so be it, but this story is just too perfect.

Sorry about accusing you to be a liar, I really struggle to do that.
But my gut says bullshit and I would be dishonest not to admit it.

I kinda wish to be wrong, because it would be an awesome undertaking,
but I don't think I am.


On Sat, Dec 30, 2017 at 10:40 PM, Kuba Ober <> wrote:
I should probably add that his wife had extensive experience in accelerator physics and was hands-on with two major projects earlier in life - so that helped. She retired early and pursues her interests with some vigor.

The project was essentially a special case, a pigeonhole that otherwise would be impossible. The magnet system was wholly insufficient for any sort of a recirculating beam, and wouldn’t likely work for resonance spectroscopy anymore due to piss poor homogeneity. But it could be measured and fed into differential equations and integrated over and that’s what counted.

The deflection electrodes and focus system were vacuum-deposited on CNC ground glass parts because my friend considers himself an engineering glass artist and would probably make his house out of glass if you’d let him. They’d probably not work for any other application and were fairly crude but his wife’s modeling indicated that it was enough.

Early prototype electrodes were degassed aluminum duct tape over glass, cut into the fancy shapes the RF antennas and electrostatics needed to be - I know nothing about the RF magic needed to get those to work, but the physicist could model it and dump the shapes that worked. The adhesive was barely sticky after degassing but once you blow on it with a heat gun it still stuck well to glass. Once that was tried out, we’d babysit two vacuum deposition chambers and dump lots and lots of silver on the glass.

The quality of the signals going to RF and deflection/focus amps was understandably atrocious - it wouldn’t have worked at all had the lady of the team didn’t figure out how to convert the whole thing into a convex optimization problem under feedback that could be then iterated into a solution would that produced desired E and H fields where the beam went. None of the RF stuff would work outside of this application, save for off-the-shelf parts.

The system would have not worked with two beams, for example - the deflection and acceleration system could only work for one particle trajectory at any given time. That trajectory could evolve very quickly over time of course, but only one beam was collimated and swept as desired. Barely, but still.

Both the DACs and the amps were quite nonlinear and had distortion on the order of a few percent, the feed system was maybe good enough not to overheat the output stages but had reflections at most connections and the SWR was something to
be ashamed of - the digitized waveforms had finite impulse response corrections applied so that the signal going out into the air was correct. Any RF engineer would look at this, rolled his eyes and walked out of the room I’m sure, muttering something about insane asylums and forced isolation.

The electrostatic amps were probably barely linear enough for some crude student demo scope, the DACs were a harmonics bonanza and leaked plenty of digital chuff in spite of my somewhat careful efforts at layout, etc.

It was a boondoggle that barely worked, but work eventually it did. The deflection resolution and accuracy at the screen was an astounding 10 bits and the acceleration voltage range was 3kV to 40kV - understandably enough you didn’t want to be anywhere near when it ran at 40kV. The deflection phase velocity at ~20kV at the screen was 3c - so better than Tek’s best afaik. Fancy math and throwing lots of bits at the problem made it work.

The whole thing was a big honking RF leak and the small steel building where they played with this stuff had to be temporarily converted into a shielded anechoic chamber lest it upset lots of people. His wife, for a Christmas gift somewhat before the project began, and after they sort of jokingly discussed the idea, had the foresight to rent her hubby an anechoic chamber as a way of bootstrapping and encouraging the work. I think it was a 50m^3 chamber or thereabouts.

They ended keeping that chamber for about 2.5 years. I didn’t even ask how much it cost. It was not a small chamber, I built an elevated plywood floor inside of it so that the floor could be anechoic as well. It was roomy enough to maneuver with equipment and not feel like you were going to be trapped and die should there be a fire. Nothing ever emitted the magic smoke and I only ascribe it to the deities looking another way the whole time. I don’t believe we were that good.

It was maybe one of the very few occasions where anyone had any reason to run FORTRAN code in a Linux kernel module. I had the pleasure of getting the gcc FORTRAN runtime playing ball with kernel environment and setting up a continuous integration environment for our physicist so that it was easy for her to deploy and test the code. A lot of the work was facilitated by employing the state-of-the art in various engineering fields, but in a sort of a rube-goldberguesque way.

None of this was anywhere near what any sort of a sensible day job engineering type of a project should have been run like.

Overall, it was a way for some slightly crazy and clever people to flex their muscles in the pursuit of something just about absolutely useless other than a distraction from daily chores. It wasn’t pretty, it wasn’t even elegant, the hardware would give most people a pause, but hey - you only live once.

Cheers, Kuba

30 dec. 2017 kl. 14:31 skrev stefan_trethan <>:

I feel like I should apologize to you because I struggle with disbelief.
This is quite an extraordinary story.


On Sat, Dec 30, 2017 at 8:11 PM, Kuba Ober <> wrote:
You’re not the only one to have thought of that. It sounds surprisingly simple in principle but turned out to be quite an endeavor. I have a buddy who is a hobbyist glassworker, as well as an EE, and an occasional concert cellist - and he loves vacuum electronic devices of all kinds. That’s why he learned glassworking. He had a similar idea and actually made one although it took way more work than he assumed initially - I have to see if I can get pictures and videos. He brazed an entire oscilloscope face to the contraption. Multiple times.

It took him half a year to get the RF controlled well enough for the concept to even pretend to work - but poorly. Then another half ear of tweaks. And that on version 2. Version 1 was another year of trials and tribulations that had to
be discarded but taught him much. He had to solve some interesting problems, some of which I will recount below.

He used two discarded magnets from surplus lab NMR spectroscopes and built up the magnetic circuit - a very rough one. He already had an old KUKA manipulator arm that he used for automating some of his glassmaking and added a 3D magnetometer probe on a long plastic boom to it in order to analyze the field homogeneity. That was prompted by the long time it took to do the measurements manually. Of course the measurements were collected by a computer and once the process was set up, it was trivial to repeat them. That’s important.

The glasswork was - in terms of shape but not manufacturing - a vertically extruded 2D spiral with rectangular cross-section, with flat plates closing it on top and bottom. It had same height everywhere but varying width. The vertical walls were shared between adjacent arms. His first approach was to build it up progressively: first close up a very short section, make it work with its small screen, then tear the screen off, build up another section, attach a bigger screen, rinse and repeat. Lots of old scope tubes were sacrificed for this, but in the end the adjustments made to the get the outer sections work threw the RF field inside off too much.

The second version, that actually worked OK, had beam position sensors distributed along the length. The RF, deflection and focus was digitally synthesized under adaptive open loop control from the beam sensors. The characterization of the magnetic field was quite important - for any beam position, the RF, focus and deflection waveforms had to take into account the magnetic field that the beam traveled through - it wasn’t too homogenous as he didn’t want to spend too much time on the magnet as it wasn’t “fun” and not his core pursuit.

His approach was fairly ingenious in order to make it tractable and I wish I had come up with it myself: the beam control was a digital playback of electrostatic signals and RF. In real time, it was open loop. But the beam position sensors were digitized and used to slowly (in relation to the sampling rates) adapt the “trajectory” of RF and deflection signals.

So this wasn’t really a real-time scope display, it was more akin to a laser show in that it was all preprogrammed. The beam trajectory evolution over time was predetermined (say a second’s worth), then the RF, focus deflection signals were generated, loaded into the digitizers, then the sequence was ran at a very low beam current and the adaptive process would read out the position sensors and tweak the waveforms until the beam safely reached the screen along the predetermined trajectory at each time instant. Then the beam current was slowly increased and the adaptation kept up with the fallout from that.

All in all it took him about two years of evenings each and every day for version 2 that worked and was quite a feat. The spiral was divided into 80 segments along its length. Each segment had a beam position sensor of a design used in particle accelerators (I have no clue about how that worked admittedly - he knew the vacuum electronics stuff), a pair of deflection electrodes, four focus electrodes, and the RF amp and antenna.

The RF, focus and deflection were played back at 4 Gs/s via 7ch 8 bit digitizers, one per spiral segment. The beam position was digitized at 8 bits at 1 Gs/s. That’s quite a bit of data to push, but it was all local to each segment.

I helped out with digitizer design - each one had an FPGA timesharing DDR2 sticks between the ADC, DAC and a 100mbit Ethernet connection. Each digitizer had 48GB of RAM across 12 x 4GB sticks in order to maintain the needed bandwidth. This was at the height of DDR2 popularity so RAM was “cheap”. Yeah, there were 80 identical digitizers that were playing back 7ch at 4Gs/s for a total bandwidth of 24Gb/s, and recording 2ch at 1Gs/s for an extra 2Gb/s.

There were also some static gradient-like coils; each digitizer fed 8 slow 16-bit DACs that went to amps and coils. I don’t recall the arrangement or function of those; his wife - as she developed the modeling code - told us that those extra coils were needed for it to work.

Raw Ethernet packets were used to get the PCs that ran the show read out the digitizers and tweak the waveforms. For the playback I ended up with textbook delta compression that cut the data rate in half so it was possible to keep 2 seconds of data in the RAM.

Digitizer-wise, everything was done as simply as possible and the adaptive closed loop control allowed to get sufficient performance. The DACs were interleaved R-2R running at 500Ms/s each assembled from 0.5% resistors - they weren’t very linear but had good repeatability and didn’t drift too fast - with closed loop control that’s all it takes. So: 56 R-2R DACs per digitizer, running off interleaved clocks and fed from paralleled latches.

No S&H of any sort, the 8 interleaved outputs for each channel were buffered, summed together, and fed to the electrostatic and RF amps. The ADCs were natsemi parts my friend got a few trays of for free. Another of his buddies designed the electrostatic amps - they were a “mashup” of design ideas from discrete Tek and Leader scope deflection amps and had about 200MHz bandwidth, I forget the deflection voltage but it was substantial. The RF amps were surplus wideband linears.

His wife did all the beam steering code design - both to model the beam trajectory and to do the adaptation. Given an overall trajectory, each segment was fairly independent so the adaptation code could be easily split among a few PCs to keep those digitizer links fully occupied. IIRC 4 digitizers each would connect to a 4-port network card in its own PC. The links were all pushing data at full bandwidth. Since the PCs had nothing to do but run the adaptation and exchange the boundary condition data with the “master”, she ended up putting the code into a Linux kernel module. So those PCs ran the Linux kernel only - the init process was just a single “sleep” call (that was my idea IIRC).

I believe that overall two man-years of effort from extremely productive and dedicated people went into it - and I’d consider my contribution to be very minor; I was at beast a fourth fiddle in all that. They had another friend who did all of the final assembly and testing of the various components.

The outside diameter of the spiral was 400mm. The screen used was from a 7k mainframe, one of the faster ones that had a smaller screen. He wanted a 7603 screen but it didn’t fit into his magnet envelope.

Cheers, Kuba

Join to automatically receive all group messages.