The HP 5370B Time Interval Counter

In the early 1980s, Hewlett-Packard introduced a new product that redefined the measurement of very short time intervals. The 5370 time interval counter has a resolution of 20 picoseconds (or 20 trillionths of a second). That's a very small amount of time: in 20 picoseconds, light travels about one quarter of an inch (what does "the speed of light" really mean?).

The 5370 (sold in both "A" and "B" versions) was available from HP for a remarkably long time; I have an HP catalog from 1997 that still shows it (with a price tag of $25,000!). It's still the highest resolution timing unit HP has offered, and even today there are only a couple of other boxes available commercially that have similar performance.

Although the 5370B is now out of production, it's still a very useful device, and I was very happy when I snagged one from eBay last summer (for a whole bunch less than $25k!).

Thanks to an anonymous friend at HP, I was able to borrow three application and product notes about the 5370 that are now long out of print. I was able to scan them, and here they are:

I wanted to determine what the performance of the 5370B translated to in terms of frequency stability, so I set up a couple of experiments. My goal was to test both its time interval measurement and frequency measurement capabilities in a way that minimizes the effect of other instabilities, so that I can characterize the counter itself. I think the time interval tests come pretty close to that goal; I'm not so sure about the frequency counter tests and I'm continuing to work on that.

Time Interval Measurement

I wired things up so that a 1 pulse per second signal went into the "start" connector of the counter, then traveled through a chunk of coaxial cable to the "stop" connector. The counter starts timing when the signal hits the start circuit, and stops when the signal has made its way through the coax to the stop circuit (about 35 nanoseconds in this case). The 5370B then displays this value and waits for the next pulse.

Effectively, this measures the speed of electrical impulses, which travel in free space at the speed of light, by determining how long it takes the pulse to travel the length of the cable. (Actually, the signal travels about 1/3 more slowly through the cable than it does in free space, but that doesn't change the experiment.)

The time delay through the cable should remain very constant as long as the ambient temperature doesn't change too much, and the system isn't physically moved around. Therefore, the counter should read the same value time after time. If it doesn't, that means there's some noise in the system -- and we know there will be because no electronic device is perfect. My goal was to measure that noise.

I took readings once per second for a little over a day (well, I didn't sit there writing things down; the 5370B has a data output that was connected to a computer which logged the data). Then I fed the results into a really cool program called Stable32 that performs all sorts of analysis on this sort of data. Here are charts generated by Stable 32 that show the performance of the counter.


This is the phase data (another term for the time interval readings from the counter) after subtracting the average time delay. This shows that the system is pretty stable -- over more than a day, there were only two readings that were as much as 100 picoseconds (1.2 inches worth of light) away from the average value. Unfortunately, the resolution of the chart hides the detail in the central region, but the vast majority of the readings were plus or minus 40 picoseconds and nearly half were right on the mean value.


This is a close-up view of a few minutes of data. It clearly shows the 5370B's resolution -- every reading is a multiple of 20 picoseconds.


Here's a histogram chart that shows how closely clustered the readings were. The plurality are right on the average, with almost no samples more than one reading plus or minus the average.


Finally, this is the chart that shows the stability of the system -- how constant the readings were over varying averaging times (called "tau") from one second out to over 30,000 seconds. This number crunching can done by the Stable32 software using various techniques. I'm using a calculation called "total variance" which has the advantage of showing better results at longer averaging times than the more traditional Allan variance. This chart shows that the 5370B is stable to about 4 parts in 10-11 (or about 40 picoseconds) for a single sample. That seems about right given 20 picosecond resolution, and the "conventional wisdom" that there's around 20-40 picoseconds of noise (jitter) in the 5370B's circuits.

The bottom line is that all these charts show that my counter is performing about as HP suggests, and the stability figures give me a baseline of how stable a signal I can measure before the stability of the measuring instrument becomes a factor. Without using special tricks, I can measure to a couple of parts in 10-10 (you can't measure right down to the measuring instrument's uncertainty) in one second. As the measuring time increases, so does the resolution and for times of more than about 1000 seconds, the counter is more accurate than anything I have available to test. To measure short (10 seconds or less) tau values more accurately, I need to use some different techniques, which will be the subject of another "science fair" experiment.

Frequency Measurement

Although the 5370B is optimized for time interval measurements, it also has the ability to directly measure the frequency of a signal with a resolution of 12 digits at the maximum standard "gate time" of one second. For various reasons, the frequency counter performance isn't as good as the time interval measurement. Here's a graph of the total deviation when measuring a very stable 10MHz reference signal for about 12 hours:


You can see that the stability at one second averaging interval is about an order of magnitude worse than when in time interval mode, and the improvement over time isn't nearly as linear. Some of this may be due to my test configuration, but in general it's clear that time interval mode is a much better tool to use for measurements than frequency counter mode.



There's also another reason to avoid using frequency counter mode. The 5370B is a great unit, but it's also somewhat old technology and its on-board computer can't do its other housekeeping while it's taking a reading. This means that there's a delay -- about 100 milliseconds by my very crude measurement -- between samples, and this "dead time" has a negative impact on the frequency stability analysis.