Test equipment to repair, part 1

I like old test equipment, particularly of the era where they had switched fully over to silicon transistors and achieved truly modern levels of performance but hadn’t gotten completely into cost-reduction — before they outsourced half of the design and production, back when companies like HP were seriously vertically integrated.

(imagine a box of random parts) HP 419A null meter. This is a null meter based around a chopper amplifier circuit which is very sensitive and was specified by HP in the calibration procedures for numerous equipment from the late-60s through the 1980s. I think it only truly became obsolete (from their perspective) after the impressive HP 3458A 8.5 digit auto-calibrating DMM was introduced. Mine was acquired cheaply, in mostly good condition — except the NiCd batteries had leaked their potassium hydroxide all over the place and the mercury cell was long since dead. It’s currently sitting in pieces in a cardboard box, I long ago finished cleaning the dirty parts off and I think I have all the replacements I need — I just need to do the tedious reassembly and see how it works. Also I’m going to replace the dead mercury cell with a CR2032 lithium and a low-quiescent-current regulator or series reference IC — It doesn’t even need to be exactly 1.35V, I think, it just needs to be there to provide a stable floating offset.


HP 3314A. This is in some sense the first notable arbitrary waveform generator, though it’s mostly easy to use as a simple function generator with sweeping, it has some awkward ability to construct arbitrary waveforms. And it doesn’t synthesize these with a microprocessor and a DAC in the modern way. No, it constructs them piecewise by integrating a digitally-controlled current source for various periods of time. I have two of these. One that fails its auto-calibration procedure on every powerup, one that sometimes fails when changing ranges, and has issues giving output with any consistency. I figure I can get one working one together out of both of them at least. It has that hefty late-70s monster feel of a half-rack 3U enclosure with a fan, 7 segment LEDs and lots of boards.


HP 5370A. This is the basic starting point of modern time interval counters and a classic time-nuts favorite. It uses some fairly complicated interpolators to exceed the resolution of conventional reciprocal counters. I have replaced the processor board in mine replaced with the Beaglebone-based replacement, HP5370 Processor Replacement Project, which makes it easy and reliable to connect to the network. However, mine is clearly a bit out of adjustment, and I need to go through the full adjustment procedure. This lead me to some other purchases including two 500 MHz scopes (a subject for another post) and the HP 8082A.


HP 8082A. This is a pulse generator with variable transition times as low as 1 nanosecond (and up to 5 volts into a 50 ohm load). Not bad for the late-1970s, and you’d still spend a lot today to exceed its specs. It has custom ECL ICs with beryllium oxide ceramic cases in the output stage! It mostly just works perfectly, which is fortunate, as the front panel slider switches are known to wear out and rely on gold plated PC board contacts to operate. Unfortunately it becomes terribly jittery above about 150 MHz (it should go to 250 MHz.) So far I’ve determined that it’s not the rate generator, because I’ve reproduced approximately the same behavior driving the external input with a reliable RF signal generator. Compared to other HP gear of the era, the service manual kind of sucks — has schematics and adjustment procedures, but it’s not really detailed about troubleshooting if things don’t work.

In the future I’ll talk about HP 3457A battery replacement and maybe fixing a 500 MHz Tek scope and some plugins (Hopefully — the 7000 series plugins are electrically brilliant but mechanically a lot inferior to their earlier work in my opinion.)

Debugging why pps line discipline gets removed after 5 seconds

I got my udev rules all set up to use an NMEA GPS board which provides PPS with ntpd:

SUBSYSTEM=="pps", MODE="0664" GROUP="dialout"
KERNEL=="ttyS0" SYMLINK+="gps0"
KERNEL=="ttyS0", RUN+="/bin/setserial /dev/%k low_latency"
KERNEL=="ttyS0", RUN+="/usr/sbin/ldattach pps /dev/%k"
KERNEL=="pps0" SYMLINK+="gpspps0"

And it almost seems to work great:

$ sudo udevadm trigger -y ttyS0 ; ls -l /dev/gps*
lrwxrwxrwx 1 root root 5 Mar 19 09:43 /dev/gps0 -> ttyS0

What? Where’s the pps device? dmesg (or journalctl) reveals:

[ 4083.237473] pps pps0: new PPS source serial0
[ 4083.237479] pps pps0: source "/dev/ttyS0" added
[ 4086.238700] pps pps0: removed

If I immediately “systemctl start ntp” after triggering udev, it seems to keep it, and ntpd gets to use pps as expected. But that’s not going to work reliably on boot. So, something’s causing it to be removed. After a bit of frusturation, I decided to poke around a bit with the excellent perf-tools

I did a lot of poking around with execsnoop and functrace, but then when I was getting inconsistent behavior, I got to looking at what had /dev/ttyS0 open. A lot of things did. Several ldattach processes! Aha. So, I reread the ldattach man page and am reminded that it resets the line discipline when killed. Presumably udev just doesn’t allow these commands to stay running in the background. So, it seems like running it as a service from systemd is the way to go, e.g: LinuxPPS wiki In my case, I did:

[Unit]
Description=Line Discipline for GPS Timekeeping for %i
Before=ntp.service

[Service]
ExecStart=/usr/sbin/ldattach pps /dev/%i
Type=forking

[Install]
WantedBy=multi-user.target

And I commented out the line with ldattach in the udev rule.

Satisfying my curiousity about the original Cockroft-Walton voltage multiplier

I was reminded of the Cockroft-Walton voltage multiplier recently, because I was thinking about building a small one for fun, and upon seeing that their development of this started in 1932, I was curious about some of the details of how they built it. In particular:

  • Were there any sort of usable high voltage solid-state rectifiers then?
  • If not, what kind of tube rectifiers were they using?
  • If hot cathodes as I would expect, how did they provide the heater supply isolated at voltages in excess of 100 kV
  • What was the output of their original multiplier?

Turns out their 1932 articles are easy to find and fairly pleasant reading:

The first article is mostly about the high voltage generator, and the second is mostly about what they did with it. In essence they produced about +700 KV and beam currents (positive hydrogen ions) on the order of 10 microamps. Most of the current was lost to corona discharge, they state that it was over half a milliampere. The interesting thing is that they did use a custom-built version of the standard hot cathode vacuum diode. The filaments were each heated by “6-volt accumulators”, which in my understanding probably means a lead acid battery. There are a lot more details about the vacuum system, naturally it takes quite a while to completely pump down the apparatus to operational levels.

Anyway, if you are interested in high voltage gadgetry or experimental physics, you should read the linked papers, they’re quite enjoyable. (Edit: Actually, there are 6 papers in that series, see this search result.)

Some impressions of Ubuntu 13.10 “Saucy Salamander”

Since I have plenty of RAM in my Mac Mini and a fast connection, I decided to torrent the ISO and install it in VirtualBox.

Unlike current versions of Debian, fresh out of the “box” it doesn’t grok resizes of the VirtualBox display.

The magic search thing you get by hitting the Ubuntu logo responds rather slowly. Even after I turned on “3D acceleration” in VirtualBox. At least it helpfully suggests things that I can buy. It appears to be doing network IO with each keystroke (to offer incremental suggestions), but unlike Google search (on their web page), it seems to be slowing down the UI with each keystroke rather than doing that work completely asynchronously.

More playing around with the UI suggests that VirtualBox’s 3D acceleration isn’t enough and it’s just doomed to be slow in VirtualBox.

I continue to be unimpressed with recent Ubuntu changes.