Keeping Time with NTP and a WWVB Radio Receiver
In 2010, Ultralink discontinued the sale of NTP receivers. This is unfortunate since they were affordable and reliable. I am keeping the information below for reference.
Almost everything in todays PC's relates in some way to time: CPU cycles, bus frequencies, graphics refresh rates, file dates, even a simple cursor blink. Correct time is one of the fundamentals for reliable and secure computing. Yet setting and keeping correct time is one of the challenges standard computers didn't solve yet. Computer time happily drifts away and relies on the user to be set, while any cheap digital watch keeps better time and is often already radio synchronized to a public time service.
Fortunately, there is a solution. In todays networked world, public servers provide time via the network time protocol NTP. These servers build a chain, were correct time is distributed down from servers that get their time from the highest accurate clocks available today.
UltraLink Model 325 WWVB Time Receiver, serial port
Wouldn't it be good to have such a root server directly in your local network? There are several ways to do that. Apart from turnkey blackbox networked server solutions ($$$), a time signal receiver can be attached to a soon to be NTP root server (off the shelf hardware), usually through a parallel or serial port. Several receiver technologies are to choose from, with GPS the most expensive. For my budget and requirements, I choose the M325 WWVB radio receiver from UltraLink. Moderate priced at $165, it is small, compact and does not need an external power supply.
The receiver gets its time signal from the atomic clock in Fort Collins, Colorado, operated by the National Institute of Standards and Technology (NIST). The radio signal is transmitted at a 60kHz low frequency and an effective power of 50KW. The accuracy reaches up to 100 microseconds and covers all States in the U.S. with the exception of Alaska and Hawaii. Hawaii got its own WWV station located on the island of Kauai near Kekaha, while Alaska is covered by the Canadian time signal. Although being located on the U.S. mainland, signal strength and good reception depends on the receiver location and placement. I had almost no reception in the office building, but have excellent full strength signal at home. On the receiver, signal reception is indicated by the green led blinking. A low blink frequency or steady green light indicates signal issues.
UltraLink Model 325 WWVB Time Receiver, inside view
Lets see what data the clock provides. Communication with the clock could not be simpler: using a standard serial connection with 9600-8N1, were I can send single character commands to it. After 'T', the clock returns a time string, while for 'I' it replies with its model and revision information. But how does the clock get its data via radio? According to the WWVB protocol, information regarding the current date and time is transmitted one bit per second in binary coded decimal (BCD) format - were four bits represent one number. Bits are recognized when when the signal power is reduced for a few milliseconds, 200ms and its a '0', 500ms and we got a '1'. It takes a full minute to transmit the 9 time digits and various other bits including separation markers. That explains why the clock needs 5 minutes to be ready after initialization. It needs some time to synchronize itself, and then a full minute after it cought the beginning of a new transmission cycle. The clock itself contains a microchip that implements a real time clock driven by a a precision quartz crystal. This ensures continous operation should there be an reception outage.
After connecting the clock to a computer, we can start integrating it into the operating system. NTP implements a daemon that compares the data from external clocks with the computers internal clock and adjusts the internal time.
Console connection via serial port at 9600 bps 8N1
Reference clock drivers allow the NTP daemon to identify the correct clock type and decode its data. Number 34 is the assigned reference clock driver number for our vendor UltraLink. Unfortunately, in NTP version 4.2.0, the newer Model 325 was not supported by this driver yet, so I sat down myself and rewrote the driver to add support for Model 325. After adding support to the reference clock driver and sucessfully compiling ntp, its time to verify it all works together. Before starting ntp, I had to create a symbolic link for the expected device file /dev/wwvb0 to the serial port device file were the receiver is connected to. Then the configuration file ntp.conf got the following lines:
server 127.127.34.0 prefer fudge 127.127.34.0 stratum 0 flag1 1
NTP clock statistics
The NTP receiver, combined with the standard Solaris 9 operating system kernel, is expected to keep time accurate to one millisecond. A higher accuracy can be achieved with special kernels working at higher time precision, combined with switching on the PPS feature in the receiver. With my feedback to the NTP team, I am now maintainer for this reference clock, feel free to send me questions and I'd be happy to help.