Keeping Time with NTP and a WWVB radio Receiver - Page 2

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.


UltraLink Model 325 WWVB Time Receiver, inside view


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. <page 3 >

Toggle Language