Date   

Re: TDS460A Firmware?

toby@...
 

On 2017-12-30 10:59 PM, Jack Rubin wrote:
I've created a new folder called "TDS460A Firmware Upgrade" which contains the files necessary to upgrade from 1.0 firmware. If you can't download the .zip file, grab the .pkg file - same thing with a different file type. You will need a DOS machine and GPIB interface to perform the upgrade.
Definitely useful to me, as a 460A owner.

What are the risks? Any calibration impact?

--Toby


Hope someone finds this info useful!




Re: TDS460A Firmware?

Jack Rubin
 

I've created a new folder called "TDS460A Firmware Upgrade" which contains the files necessary to upgrade from 1.0 firmware. If you can't download the .zip file, grab the .pkg file - same thing with a different file type. You will need a DOS machine and GPIB interface to perform the upgrade.

Hope someone finds this info useful!


Re: A "collection" with quite a few Tek 'scopes

Dano
 

I really like his video's. He doesn't talk too fast that you can't follow along, if anything he might draw it out too much, but I don't mind that. Plenty of technical details for my skill level.

However, once he switched to Patreon, I dropped off. Is he worth it, I'm confident he is, but not through Patreon, for me. That whole scheme rub's me wrong (the company, not Carlson). I don't believe their propaganda, and their track record isn't exactly stellar. Matter of fact, it just got worse, if they implement the new double-dip pay scheme.

Anyhow, I'm glad to hear he's still posting publicly on YT. I'll go back to and see what's new, when I have time to kill...

Cheers!

-Dano


Re: 7K mainframes common-mode input range?

Ed Breya
 

Thanks David, for refresh of the link to Hakan's - I've seen many of the documents there but always seem to misplace my downloaded ones. I was using the info on the PS ratings listed in the 7A17 manual, which make sense being there since it's for DIY plug-ins, more or less. The power is indeed quite limited for serious high speed logic circuitry, but I'm trying to live with it rather than adding a switcher. For example, I have some relays to drive, and they will run from the +15 into the +5, so the coil currents will add to the +5 output availability. I've got the ECL down to a minimal number of pieces, just for the fastest stuff, then 74HC for the rest.

Ed


Re: TDS460A Firmware?

Dano
 

LOL

How did I know that would happen!#@!

Well, I have to admit, when I was searching for it previously (about a month ago), I think the Tek groups were moving from Yahoo to here and every time I tried to pull up an article, it would say it didn't exist. All I could do was look at the "cached" page and that was only good for the first page. Gave up cuz it was annoying the hell out of me. Then, I tried to join the Tek group, but it wouldn't let me. It wasn't until a few weeks ago that I was finally able to join the group and realized it was due to the fact the group was moving. Sure had Google search results completely f*d up, for well over a week.

Anyhow, thanks for pointing out the obvious. (hind sight....)

I'll go and read that thread.

Cheers!

-Dano


Re: TDS460A Firmware?

Malcolm Hunter
 

Did you see this thread on the Tek forum?

https://forum.tek.com/viewtopic.php?t=132532

Seems you need to use the GPIB. They also talk about using DOS/Windows 95 for that.

Malc

On 31 December 2017 00:46:51 nojunkmail@cd-envisions.com wrote:

Anyone have newer firmware than v1.0e for the TDS460A series?

I'd like to update mine to newer, as I did read there were a few operational bugs fixed. Plus it'd be cool to add FFT option to mine, just cuz...

I know there is newer firmware, from screen shots I've seen on the web, but haven't found a single edition of the firmware on the 'net. Maybe I'm looking for the wrong thing. How did they update the firmware in the field or did they? Floppy, GPIB, Serial, burn it? That'd help narrow my searches, some more, but that's not really the problem here, it's that there isn't that many results to begin with.

It's also possible that the 460A is compatible with the others in that series, but I don't like taking chances when it comes to the firmware. Seems like the 460A is fairly ignored. Tons more info for the non A's, and everything else in that series, but not so much with the 460A. And then, depending on which book you look at there are more models lumped together in this "series". Which one do I believe?!?

Anyhow, if you have newer firmware on file, that'd be great! (said in Lumbergh's voice... office space reference Lol)

TIA!

-Dano


TDS460A Firmware?

Dano
 

Anyone have newer firmware than v1.0e for the TDS460A series?

I'd like to update mine to newer, as I did read there were a few operational bugs fixed. Plus it'd be cool to add FFT option to mine, just cuz...

I know there is newer firmware, from screen shots I've seen on the web, but haven't found a single edition of the firmware on the 'net. Maybe I'm looking for the wrong thing. How did they update the firmware in the field or did they? Floppy, GPIB, Serial, burn it? That'd help narrow my searches, some more, but that's not really the problem here, it's that there isn't that many results to begin with.

It's also possible that the 460A is compatible with the others in that series, but I don't like taking chances when it comes to the firmware. Seems like the 460A is fairly ignored. Tons more info for the non A's, and everything else in that series, but not so much with the 460A. And then, depending on which book you look at there are more models lumped together in this "series". Which one do I believe?!?

Anyhow, if you have newer firmware on file, that'd be great! (said in Lumbergh's voice... office space reference Lol)

TIA!

-Dano


Re: 7K mainframes common-mode input range?

 

The only documentation that I am aware of which discusses the power
and current limits of the 7000 power supplies is the Tektronix one
which discusses the 7704A, 7904, and 76xx power supplies:

http://hakanh.com/dl/docs/hardtofind/7k_PS_currents.pdf

Some plug-ins converted a higher voltage supply to a lower one to
provide enough current. 7D15 uses a switching power supply to convert
-15 volts to -5.2 volts for ECL. The 7D01 uses an inverter to convert
the +15 and -15 volt supplies to -4.8 and -2.0 volts for ECL. I think
someone mentioned here that it was so power constrained, that they
used a slightly lower voltage. The -2.0 volts is used specifically
for ECL termination also saving power so they must have been
desperate.

On Wed, 27 Dec 2017 17:13:52 -0800, you wrote:

Yup, that's what I have - the PECL output bias currents go through the dropping Zener/R networks and then larger resistors all the way down to the -15V supply. They act more as constant current sources, and may even improve the speed by keeping the quiescent emitter currents nearly the same in both states, but the main function is to pull enough current while not being so low in R that the 50 ohm environment is hard to achieve. The outputs are Schottky-clamped in case things get out of hand with the -15V termination. As you can imagine, it's not power-efficient at all, but only needed at certain spots, so not too bad overall - wouldn't want to do all the outputs with such loads.

Speaking of power, it is my understanding that the +/-15V and +5V supplies are rated up to 500 mA each - but not all at the same time of course - as long as total (single-wide) plug-in power is less than 16.5W. Does anyone have info or advice to the contrary? I don't think I'll have anything near the maximums, but do need to run a 1 GHz PLO at 130 mA from -15V, plus two or three of these high power ECL shifter/terminations up to 40 mA per set. The +15V needs maybe 200 mA for amplifiers, while the +5V will run all the PECL Vcc, maybe 400 mA or so. I'm picturing less than 10W for the major items, leaving a few for miscellaneous.

Ed


Re: First draft of the Tek knob visual index project

Dano
 

I am interested in helping with this project. I don't have Solidworks skills, but I do have 3D modelling skills (Mastercam). Solidworks is in progress, but that's the difference of learning gimp vs photoshop (bad comparison I know, but you get the idea).

Anyhow, I have a Tek manual on specifications that also contain "blueprints", with dimensions and all that. Not truly blueprints, but good 'nuff for what were doing, I believe. I just picked it up off of flea-bay and is called the "1988 Mechanical Catalog: Volume 2". I bid against someone else, but I was determined not to miss this, since I don't trust the other buyer to scan it in and share it, as I do. Plus it happened to be local to me - which just about never happens.

Does anyone else have the other Volumes?

There's gotta be volume 1 out there at a minimum, if it hasn't been destroyed - as so eloquently stated in the book

Quote from first page, "DO NOT SEND YOUR OUTDATED CATALOGS TO THE COMMON DESIGN PARTS CATALOG GROUP. PLEASE SEND OUTDATED CATALOGS TO SALVAGE."

I have somewhat limited access to HAAS CNC machines, so I can make "some" things, if I don't take too much machine time away from the shop. I envision that I could probably easily make faceplates (out of plastic) on the CNC, with probably better results than a 3D printer (and a lot less work). Knobs, might be more difficult. Fixturing (holding) is probably the most difficult thing for me to do on the CNC with these types of widgets. Never tried to make an angled knob - I'm still relatively new to machining processes (couple years in school only gets you to entry level) but it sure as heck won't stop me from trying.

Cheers!

-Dano


Got help thanks (Re: Need OEM 7D20 service manual help)

Artekmedia <manuals@...>
 

All

I have a volunteer to help me out

Dave
manuals@artekmanuals.com

On 12/30/2017 4:45 PM, Artek Manuals wrote:
I am cleaning up an old scan ( circa 2004) That I did of the 7D20 service manual. I don't need any scanning help but I need someone with an original OEM paper manual to tell me the lettering in some of the gray note boxes on some of the schematics. There are several free downloads but they seem to have had the same problem I had in 2004 getting the gray note boxes scanned and most are solid black.

Will make it worth your while, contact me off list at manuals@artekmanuals.com
Dave
manuals@artekmanuals.com
--
Dave
Manuals@ArtekManuals.com
www.ArtekManuals.com


Re: Need OEM 7D20 service manual help

Dano
 

Keeping it short and sweet. Check your email...


Re: 7A29 overshoot

Nenad Filipovic
 

On Sat, Dec 30, 2017 at 10:33 PM, cmjones012003 <chris@stumpie.com> wrote:
I looked at the 7904A calibrator output on my sampling scope, which
should give as accurate a picture as I can manage, and that shows a bump
just the same:
https://photos.app.goo.gl/F3MUCs38rUW5e9my1
<https://photos.app.goo.gl/F3MUCs38rUW5e9my1>

Thanks for the image Chris, so those calibrators are more-less the same.
I have posted photos from this thread to a group album named "7A29
feed-beside compensation adjustment", you can add your image(s) to it if
you wish, the album is public.
Hope you also manage to fix your units in a similar way,

Best Regards,
Nenad Filipovic


On Sat, Dec 30, 2017 at 10:33 PM, cmjones012003 <chris@stumpie.com> wrote:

On 30 Dec 2017 5:12 p.m., "Pjotr Tolstiakov" <ilmuerte@gmail.com> wrote:

Now that fear of ruining a good calibration was out of the way, I got
medieval on feed-beside COMP 1-7 plus GAIN and here's the result:
http://www.nfilipovic.com/content/electronics/7A29_1kHz_
Calibrator_After_LF_
Calibration.jpg
Adjustments interact and take a dozen of loops to get right. Now GAIN is
approx. midway and everything looks much better. There is some residual
overshoot left:
http://www.nfilipovic.com/content/electronics/7A29_1kHz_
Calibrator_7854_Overshoot.jpg
but this is far into the hi-freq territory. 7A24 showed an almost identical
overshoot, I moved them both to a 7104 where the result was very similar.


Great result! That's a really worthwhile improvement. I think that
100ns-ish bump just after the rising edge may be there on the calibrator
output, if the 7854's is anything like the 7904A's. I looked at the 7904A
calibrator output on my sampling scope, which should give as accurate a
picture as I can manage, and that shows a bump just the same:

https://photos.app.goo.gl/F3MUCs38rUW5e9my1

I hope the photo is visible.

Chris




Re: Curved CRTs?

 

On Fri, 29 Dec 2017 01:16:25 -0800, you wrote:

On the other end of the extreme I recall reading about the US-Russian
nuclear reduction exchange, and the US showing the Russian inspectors the
"fast" US scopes and them being somewhat unimpressed because it turns out
the US scopes had to fit in a rack mount which limited there size and thus
length, deflection and speeds, The Russians used long 6 foot (might have
been 2 meter) CRTs tubes and a dark box to put you head in to get multi GHZ
scopes.

Can't seem to find any links

John
That is one of the great stories to be found on the list. Here is
what Steve had to say in his message from Sun, 26 Aug 2012:

The Russian scopes certianly leveraged the design topologies, but wre their own designs. In some cases, they actually exceeded Tek's performance, lending to the designs were done much later, when higher performance components were available.

For the transient digitizers (regarded at the time by the US state department as some of the crown jewels of the nuclear weapons development) it was embarassing to find out that the Soviet technology was MUCH further developed than Tek's. I was working in the division that developed the digitizers at the time. At the end of the cold war, there was actually an exchange where the Soviet nuclear weapons designers came over to watch a US test, and our scientests did the same, going over to watch one of their last tests. When their scientests came here, the researchers at EG&G (who the government contracted to instrument the test shots) assumed that they would be wowed by the 5 GHz digitizers that Tek provided. They were not. Instead of asking how we built such fast digitizers, their only question was how do we drill the holes in the rock for the tunnel so smooth? They used dynamite to carve their test tunnels, leaving a broken rock face.

Their digitizers at the time worked at 13 GHz. The secret? The problem with building very high speed CRT deflection is charging the capacitance of the deflection plates. To get decent deflection angle, it takes a few volts/div. That is a lot of current to pump into and out of the plates which act as capacitors. So the Soviets kept the deflection angle down. Way down. Their scan converter CRTs were nearly 6 meters long! The US government labs made a requirement that the digitizer must fit into a standard 19" instrument rack. This "artificial" restricion limited Tek to 5 GHz, and even achieving that took a lot of technology development!

Their pragmatic approach allow them to achieve may things we struggled hard with in the US.


Re: First draft of the Tek knob visual index project

 

I will take a look if you send it to me. An email attachment will
work fine or provide a URL.

The only Tektronix 500 series oscilloscope I have is the 547 with a CA
and 1A1 amplifiers. Examination of your PDF will give me an idea of
what kinds of photographs you want.

I also have a Lavoie LA-265A which is a clone of the Tektronix 545A
with the Lavoie clone of the Tektronix CA amplifier. It uses
different knobs which is no surprise so I doubt it would be of any use
for your project but let me know.

On Sat, 30 Dec 2017 12:51:05 -0800, you wrote:

I have a 12 page PDF I can send to anybody interested of the beginning of the project, to show knob pics, data, layout format and other details. It is much too early to post, as only 3 sections are started, but I would like to get comments, error corrections, additional data and any suggestions if you feel like proofing it. just email me (off-list) to get a draft copy.

I especially need good pics of OLDER Tektronix knobs (or knobs I can photograph), from the 500 scope series and related vintage instruments, as I do not have many here, and none have part number data so far. this one area will really need some research work.

all the best for the new year to everybody.
walter (walter2 -at- sphere.bc.ca)
sphere research corp.


Re: Curved CRTs?

stefan_trethan
 

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.

ST

On Sat, Dec 30, 2017 at 10:40 PM, Kuba Ober <kuba@mareimbrium.org> 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 <stefan_trethan@gmx.at>:

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

ST

On Sat, Dec 30, 2017 at 8:11 PM, Kuba Ober <kuba@mareimbrium.org> 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





Re: A "collection" with quite a few Tek 'scopes

Dave Daniel
 

The link works for me.

DaveD

On 12/30/2017 2:51 PM, Raymond Cote wrote:
Link does not work. I’ve been trying!’n

Women and cats will do as they please, and men and dogs should just relax and get use to the idea.

-Robert Heinlein

On Dec 30, 2017, at 15:01, Twig <ki6j@hotmail.com> wrote:

The instrument is a Specific Products model WWVC receiver for WWV signals. Crystal-controlled, with a Collins mechanical filter. Quite the thing back in its day.

The manual is available online.

Here is one in operation: https://www.youtube.com/watch?v=L1EiLRfKgTg

If you suddenly feel the need to have one for your very own, PM me -- I have one holding down a corner of the shelf :-)



Re: A "collection" with quite a few Tek 'scopes

Artekmedia <manuals@...>
 

No problem here with the link ..likely a firewall or virus software block on your end
Dave
manuals@artekmanuals.com

On 12/30/2017 4:51 PM, Raymond Cote wrote:
Link does not work. I’ve been trying!’n

Women and cats will do as they please, and men and dogs should just relax and get use to the idea.

-Robert Heinlein

On Dec 30, 2017, at 15:01, Twig <ki6j@hotmail.com> wrote:

The instrument is a Specific Products model WWVC receiver for WWV signals. Crystal-controlled, with a Collins mechanical filter. Quite the thing back in its day.

The manual is available online.

Here is one in operation: https://www.youtube.com/watch?v=L1EiLRfKgTg

If you suddenly feel the need to have one for your very own, PM me -- I have one holding down a corner of the shelf :-)


--
Dave
Manuals@ArtekManuals.com
www.ArtekManuals.com


Re: A "collection" with quite a few Tek 'scopes

Raymond Cote
 

Link does not work. I’ve been trying!’n

Women and cats will do as they please, and men and dogs should just relax and get use to the idea.

-Robert Heinlein

On Dec 30, 2017, at 15:01, Twig <ki6j@hotmail.com> wrote:

The instrument is a Specific Products model WWVC receiver for WWV signals. Crystal-controlled, with a Collins mechanical filter. Quite the thing back in its day.

The manual is available online.

Here is one in operation: https://www.youtube.com/watch?v=L1EiLRfKgTg

If you suddenly feel the need to have one for your very own, PM me -- I have one holding down a corner of the shelf :-)



Need OEM 7D20 service manual help

Artekmedia <manuals@...>
 

I am cleaning up an old scan ( circa 2004) That I did of the 7D20 service manual. I don't need any scanning help but I need someone with an original OEM paper manual to tell me the lettering in some of the gray note boxes on some of the schematics. There are several free downloads but they seem to have had the same problem I had in 2004 getting the gray note boxes scanned and most are solid black.

Will make it worth your while, contact me off list at manuals@artekmanuals.com
Dave
manuals@artekmanuals.com

--
Dave
Manuals@ArtekManuals.com
www.ArtekManuals.com


Re: Curved CRTs?

Kuba Ober
 

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 <stefan_trethan@gmx.at>:

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

ST

On Sat, Dec 30, 2017 at 8:11 PM, Kuba Ober <kuba@mareimbrium.org> 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



40221 - 40240 of 183422