Category Archives: Uncategorized

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:

Description=Line Discipline for GPS Timekeeping for %i

ExecStart=/usr/sbin/ldattach pps /dev/%i


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

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.

Debian Wheezy (7.1) on Lenovo Ideapad S12

Here’s what I needed to do to get it to work. First, you need proprietary drivers for the 802.11bgn chipset (BCM4312 with LP-PHY). It should be possible to provide this non-free firmware at install time, but I never got that to work so instead I just installed with the wired ethernet and installed this firmware later on the running system by adding the “non-free” and “contrib” repositories to /etc/apt/sources.list and doing:

apt-get update
apt-get install firmware-b43-lpphy-installer

This may require a reboot to take effect, there’s probably another way, but it’s more effort.

You’ll probably also want the proprietary NVidia display driver if you have the NVidia ION chipset variant of the S12. Just follow the instructions at NvidiaGraphicsDrivers for installing the current version using DKMS. Reboot again, or you could reboot once for all three of these changes.

Suspend seems to immediately wakeup due to USB interrupts. Putting the following in /etc/rc.local (and rebooting or executing the script as root) seems to fix that:

for i in 0 1 2 3 ; do
echo USB$i >/proc/acpi/wakeup

Those are the USB controllers, it still wakes up fine from hitting a keypress.

You may also want to add some of the recommended tweaks from powertop. A way to get them in scriptable form is to run it as powertop --html=<filename> option and cut end paste some of that into rc.local. I got things down from about 17 watts to 12 watts on battery.

I haven’t tried to mess with the built-in camera yet.

Bad UI: Error messages you cannot copy and paste

If I get some kind of mysterious error, don’t make me manually retype into my web browser to search. That’s completely ridiculous.

An example:

Admittedly, there’s a link that searches help for the error, but it doesn’t find anything relevant, so I have to go search the web anyway. I’ve seen examples of this from Apple as well on occasion, but I don’t have any handy right now.

By the way, that error is explained by Microsoft here. You’d think with 32 bit error codes like that it would be easy to link to[error code] which would automatically go to the explanation. Or maybe put explanation strings in the application’s message catalogs or whatever. This isn’t 1980.