RADIOCLKD(1)						   Network Time Protocol Daemon 					      RADIOCLKD(1)

NAME

       radioclkd - decode time from radio clock(s) attached to serial port

SYNOPSIS

       radioclkd [ -tphv ] device

DESCRIPTION

       radioclkd  is  a  simple  daemon  that decodes the time from a radio clock device attached to the DCD and/or CTS and/or DSR status lines of
       serial port of a computer. It is able to decode the DCF77, MSF and WWVB time signals. The received time is then	sent  to  ntpd	using  the
       shared  memory reference clock driver. The type of time signal being received is automatically determined. If you have problems getting the
       program to work using interrupts, the following command is known to help in many instances. If this fails you can always fall back  to  the
       polling method.

	      stty crtscts < /dev/ttyS0

       Details on a cheap and easy to make device for receiving these time signals can be found at

	      http://www.buzzard.org.uk/jonathan/radioclock.html

OPTIONS

       -p, --poll
	      Poll the serial port for changes of status in the DCD, CTS and DSR lines rather than use interrupts

       -t, --test
	      Enter  test mode printing the length of each pulse and the decoded time at the end of each minute on stdout. The time is not sent to
	      ntpd using the shared memory reference clock driver in this mode.

       -h, --help
	      Print a short synopsis of the command line arguments.

       -v, --version
	      Print the version number and then exit.

CONFIGURATION

       Configuration is very simple. Use server 127.127.28.0 in your ntp.conf file for a clock attached to the DCD line, server 127.127.28.1 for a
       clock attached to the CTS line, and server 127.127.28.2 for a clock attached to the DSR line. You will also want to use a fudge line on the
       server to change the displayed refid.

CALIBRATION

       Due to delays in the propogation of the radio signal, it's processing by the receiver board and the latency of  the  operating  system  the
       time  decoded  by the receiver will be slightly offset from actual UTC. Typically this delay will be less than 20ms, so unless you are very
       fussy about the time, or are using more than one time source, such as a GPS unit, other radio clock or NTP server on the internet  you  can
       ignore this section.

       The  basics  of	the  calibration  procedure  is  to  determine the average offset of the radio receiver, and use the time1 fudge factor in
       ntp.conf to bring the receiver as close as possible to the real time. The easiest way of determining the offset of the radio receivers time
       is  to  run it against a reference clock that does not suffer from these problems. The best reference clock would be a GPS unit. This might
       be a GPS unit that you don't wish to dedicate to time keeping, or a borrowed unit. If this is not possible you could use a stratum 1 server
       on the internet.

       The  method  of	calibration  is quite simple. We attach the calibration reference clock to the computer and fudge the stratum of our radio
       receiver up to say 5.  This way we can be sure that ntpd will lock onto the calibration reference clock. We need to make sure that ntpd	is
       configured to collect peer statistics so make sure we have some lines similar to these in ntp.conf

	   statsdir /var/log/ntpstats/
	   statistics loopstats peerstats clockstats
	   filegen peerstats file peerstats type day enable

       After  that  we restart ntpd and leave it running for several hours. We can then make a copy the peerstats file. The trick is to remove all
       the entries before ntpd has come into close aggrement with the calibration reference  clock  and  then  run  the  peer.awk  script  in  the
       scripts/stats  directory  of the ntp distribution. This will give us a mean offset of our radio receivers in milliseconds. This can them be
       converted into seconds and added to the fudge line in ntp.conf for our receiver.

       The final step is to remove the change in stratum level for our reference clock and restart ntpd. If you move the receiver any  significant
       distance  then  you will need to repeat this calibration step. Across the room or around the current building will be fine, but if you move
       it to the next town/city then you will need to recalibrate.

IN USE

       The version of ntpd that comes with most Linux distributions does not have the shared memory reference clock driver compiled in by default.
       This  can be identified by checking the logs after ntpd is started. If the shared memory reference clock driver is not compiled in then the
       logs will contain warnings about the reference clock driver not being recognized. To compile ntpd with the shared  memory  reference  clock
       driver you must specify the --enable-SHM option when running configure.

       Neither	radioclkd  or  ntpd  ever  mark the shared memory segment for deletion. If you stop using the shared memory reference clock driver
       therefore any shared memory segments will persist until you reboot or manually delete the segment using ipcrm.  The segments can be identi-
       fied as the one with key 0x4e545030, 0x4e545031 or 0x4e545032 using the ipcs command.

BUGS

       If  you	are  running a kernel with the PPS kit and have a clock attached to the DCD line you may experience lockups. If you encounter this
       problem the currently recomended solution is to move the clock to either the CTS or DSR lines.

AUTHOR

       This program was written by Jonathan Buzzard <jonathan@buzzard.org.uk> and may be freely distributed under the terms  of  the  GNU  General
       Public License. There is ABSOLUTELY NO WARRANTY for this program.

Version 1.0							    19 Jan 2003 						      RADIOCLKD(1)