Leap Second 2005

Like all good time-nuts, I looked forward to the leap second that was added at midnight UTC this past New Years Eve. There's no way to predict more than about six months in advance whether a leap second will be needed to compensate for the gradual slowing of the earth's rotation, and this was the first one to be added since the end of 1998. That's a long time in the computer world, and a lot of new software has been written since then, much of it completely unaware that leap seconds even exist.

So, I decided to test as much of my gear as I could, and record the timecode from as many sources as a could, to test things out.

But from a geek-chic perspective, clearly the most important thing was to take a picture of a radio-controlled clock as it showed the leap second (either by duplicating the 23:59:59 second, or adding a 23:59:60 second). Although I have lots of timekeeping gear, I only have one radio receiver that has a digital time display, a Spectracom 8170 WWVB receiver. So, I aimed my camera at it (the other clock shown is an HP 5065A Rubidium frequency standard; it's manually-set and ignored the leap second):

It's almost time. What will happen next?

What's this? No leap second?

Nope.

But a few minutes later, the Spectracom stepped back a second.

(It added another ":59" second at 00:03:59, but I missed getting a picture of that -- see further down for an explanation of how the Spectracom receiver handles leap seconds).

Most of my leap second effort was in recording the radio signal from several sources. I used a four-channel sound card to capture all the signals in a synchronized way. Here's a screenshot of the Audacity audio editing software at work:

The top stream is WWVB, followed by CHU, WWV-10MHz, and WWV-5MHz.

Here are short audio clips of each signal from 23:58:46 through 00:01:05, in both WAV (2.23mb) and MP3 (140kb) formats (to help my bandwidth, please download only the MP3 unless you really need the WAV version). They were recorded at 8000 samples/second and 16 bits.

If you'd like a full 2-hour version (about 115MB WAV) of any of these signals, email me and I'll get them to you.

By the way -- while the four recordings are synchronized in time to well under 1 millisecond, you will notice that the 10MHz WWV signal (the third track) lags the 5MHz one (the fourth track) by a very noticeable amount. This is because the SDR-1000 receiver used for the 10MHz signal does its signal processing in a PC, and that process introduces quite a bit of delay (or "latency") to its audio output.

If you're interested in the recording technique I used, read on.

That's my operating position. On the cart to the left are two HP 3586C selective level meters, which are about the most useful pieces of gear for any sort of high-frequency measurement. The top receiver was tuned to CHU on 3330kHz (actually, the receiver was tuned 1.850kHz above that frequency to properly receive the upper sideband signal).

The second receiver was tuned to WWVB at 60kHz. Since there's no voice modulation, the output was an 1850Hz tone which carries the 10dB carrier level changes used for the WWVB timecode.

At the right side of the wood shelf above the main desk, you can see a tiny box. That's a Yaesu FT-817 low-power transceiver that was tuned to WWV on 5MHz.

At the left side of the glass shelf above the side desk, you can see a featureless black box. That's a Flex-Radio SDR-1000 software defined radio. It uses a PC and sound card to perform its signal processing; the shoebox shaped thing on the right side of the side desk is a Shuttle PC with 2.4GHz Pentium IV processor doing that job. It is, alas, running Windows 2000 to support the SDR software. Since there isn't room for a second monitor on the desk, the SDR computer is controlled using the VNC remote control protocol; I access it from a window on the Linux display.

Below the desk on the right, you can see part of a tower case on the floor. That's a Linux machine (Athlon 2200) with Delta44 sound card that was doing the recording. It is connected to the monitor on the main desk.

For WWVB and CHU, the HP level meters were fed by an AMRAD LF antenna with low pass and high pass filters to notch out the strong AM broadcast band signals. The two WWV receivers shared a Gap Titan vertical ham antenna.

The four receive audio streams were fed into the Delta44 sound card and processed with the Audacity audio editing software.

One minor challenge was that the 3586C meters don't have any form of automatic gain control. I made manual adjustments (in 5dB steps) as needed to keep the audio levels for WWVB and CHU at a reasonable level.

Finally, I also recorded the serial data stream from my Spectracom 8170 WWVB receiver and an HP Z3801A GPS disciplined clock. I also did a dump of the system timer information from a Linux machine running NTP (slaved to another Z3801A).

As noted above, the Spectracom didn't react to the leap second until four minutes later:

53736.00274 001 00:03:58 TZ=00
53736.00275 001 00:03:59 TZ=00
53736.00277 001 00:03:59 TZ=00 <----
53736.00278 001 00:04:00 TZ=00
53736.00279 001 00:04:01 TZ=00

After re-reading the Spectracom manual, it looks like the receiver ignores the WWVB leapsecond flag entirely. It sees the leapsecond only when it gets a data frame that puts the minute marker at a different time than it thinks it should be. It then waits for two more data frames to match, in order to be sure the first one wasn't a fluke. Then, at the end of 00h03m it assumes something happened and resets according to the new data by holding an extra second at 00:03:59. To quote from the manual:

Once the Time Sync light is on the clock will keep UTC time. The display will be changed when 3 consecutive good compares are received that do not agree with the display data. This will happen when the leap second is inserted.

The Z3801A did almost exactly what it was supposed to, though the leap second flag (the "+" sign) didn't clear until one second after the fact:

53735.99997 T22005123123595830+0042
53735.99998 T22005123123595930+0043
53735.99999 T22005123123596030+003B <----
53735.99999 T22006010100000030+001E
53736.00000 T2200601010000013000024

I haven't figured out how to analyze the system timestamp data yet...

If you'd like to download the data to play with yourself, here you go. The "full" version covers several hours, while the "short" version is centered on the leap second transition (the system time generates dozens of readings per second; the full version covers 4 minutes and the short version just a few seconds around 00:00:00).