A Multi-Channel PPS Logging System
Using Surplus Components

To determine the aging and other long-term stability characteristics of a frequency standard, or to measure frequency offset with great accuracy, it's most convenient to use a counter measuring the time interval (or phase) between a pulse-per-second ("PPS") signal from the device under test and one from a reference source such as a GPS receiver. For many of these measurements, it's only necessary to do one measurement per hour, or even one per day. Since these are often long-term measurements, it seems a waste to dedicate one time interval counter to each such measurement.

To work around this, I decided to build a PPS logging system that could support multiple measurements using a single counter. The resulting system consists of inexpensive surplus equipment plus a Linux-based PC. As currently configured, it can measure up to seven units under test against up to seven reference signals in any combination. Slight changes of cabling and software configuration could allow up to 13 UUTs against 4 references; a smaller configuration is also possible using less hardware.

This paper describes the hardware and software used to implement this system. It's written as much as my own documentation as for the eyes of others, so forgive any excess level of detail.


Time Interval Counter
The first key piece of the system is a surplus HP 5334A (or B) time interval counter. This is a small, inexpensive (usually well under $200 on eBay), fanless counter with a single-shot resolution of 2ns. It has a 100-gate average capability that provides 200ps resolution. Given the noise of most GPS receivers, 2ns resolution is plenty and the 5334 works very well in this application. Its only negative compared to more sophisticated counters is that it cannot measure negative time intervals. This causes some complications, but they can be addressed in other parts of the system. Critically, the 5334 can communicate with a computer via the GPIB bus. The 5334's reference clock is driven by the house 10 MHz frequency standard (normally an HP 5065A Rb whose frequency is monitored by this system).

Coaxial Switch
The second important part is one or two HP 59307A coaxial switches. These are ancient devices but tremendously useful in the lab. The 59307A is a dual four-position switch with BNC connectors. It can be controlled via GPIB and thus allows the computer to select various input sources to be fed to the 5334 counter.

Here is a table showing the switch connections I am using.

HP refers to the two switches in each unit as "A" and "B" and the positions on each as 1 through 4. So, "A1B4" represents one combination of the two switches in one 59307A unit.

A minimal version of this system could use a single 59307A switch. The most obvious configuration is to use one side of the switch to route one of four inputs to the start input of the counter and the other side to route four inputs to the stop input. But if you have only a single reference source, you could feed that directly to the stop input and put both sides of the 59307A in series with the output from the B switch going to input A4. That would allow selecting one of seven input signals.

I am using two 59307A switches, one configured to deliver seven inputs to the start channel, and the other to deliver seven inputs to the stop channel. If you have to measure a *lot* of sources, you could easily change the configuration so allow as many as 13 units under test with a single non-switched reference source. You should get the idea that this is a very flexible and expandable switching system..

PPS Generation
For those frequency standards that don't directly provide a PPS source, I use TAPR TADD-2 Mini PPS dividers. Every time nut needs to own several!

I've built four T2-Mini's into a panel (click on the image for a full-size version):

Here is more information about the panel and divider wiring.

PPS Distribution I use PPS signals to drive NTP servers as well as for other measurements in the lab, so I use a pair of TAPR TADD-3 PPS distribution amplifiers, each configured to provide three outputs from each of two inputs. One output goes to the 59307A switch system, another is available for NTP use, and the third is routed to a patch panel so it's available for temporary use as needed. Currently, the four signals handled this way are from the CNS-2 GPS, Z3801A GPSDO, Spectracom 8170A WWVB receiver, and HP 5061A cesium.

Computer I use a small Intel "Atom" based computer with a solid state disk drive and a surplus National Instruments PCI-GPIB card. It's running Debian 6.0 and uses the linux-gpib hardware driver/library to talk to the GPIB card.


The idea behind the system is to use the system cron daemon to periodically trigger a shell script, which in turn runs a data logging program. Based on the options given it, the data logging program:

The shell file contains multiple lines, each setting the appropriate switch position and loggin to its own data file. When triggered by cron, the shell script will trigger each measurement in sequence.

Running from cron
Triggering measurements via the crontab file has one potential disadvantage: its resolution is one minute, so it's not directly possible to set up a measurement interval of, say, 10,000 seconds. It looks like there is an alternative program called frcon that may be able to trigger a command every X seconds. I haven't had a chance to look into it closely enough to see if it would work. Another alternative would be to write our own simple program (perhaps using the Perl "alarm" function that I documented here. But for now, I'm just going to run once per hour and live without having taus on second decades.

Apart from setting the execution time with greater resolution, another concern is whether triggering from cron will have too much jitter -- in other words, does the cron job fire off exactly when you think it will? To test this, I ran the system for a couple of days set to take 5 measurements every 10 minutes. I then looked, not at the phase data, but at the timestamps (logged in MJD format) and measured the first differences -- the variation in time from one measurement to the next. I plotted the results as shown below.

This shows that while there is some jitter in the timing, it is never more than one second, that it is not cumulative, and that the occurrence is about the same in both the positive and negative directions. It also shows that most of the time all of the measurements in a given set were delayed, indicating that the cron program triggered a bit early or late, but on at least a few occasions only one of the measurements in the set was affected (e.g., the cyan spikes near the middle). That would indicate that an individual measurment was delayed for some reason, rather than the trigger for the whole set (or perhaps the measurement was on time, but the timetag calculation was in error for some reason).

Assuming a normal measurment interval of one hour (3600 seconds), this occasional one-second jitter shouldn't have significant impact on the quality of the data.