UPDATE 9 nov 2008: Currently ntp2.remco.org runs with the configuration mentioned below. Polling time for the PPS peer is 32 seconds (minpoll 5, maxpoll 5). Stats can be viewed here.

UPDATE 8 aug 2008: As I already felt, the idea below is already implemented by Poul-Henning Kamp in his own implementation of a NTP-server, NTPns. I am trying to figure it out and will report the results here as soon as I got it running.

This post tries to describe an experiment using DCF77 pulses as PPS source. Although seemingly trivial, I could not find any information on the web dealing with this issue, therefore I publish it here. Presumably the following ‘discovery’ is already implemented in ntpd and/or its refclock-drivers. I am more into hardware.

Anyway. . . . enough disclaimers!

Today a friend of mine returned one of my DCF77 radio modules because ‘it didn’t work anymore’. Before he returned the module, he took a picture of it. Well… the ferrite antenna rod was missing, presumably ‘lost’ during a relocation of the server the module was connected to.

The module was interfaced to RS232 in conjunction with radioclkd2. I use(d) the PARSE/GENERIC driver on ntp.remco.org and for this driver the RS232 connector needs to be rewired.
Below the RS232 wiring is explained for a DB9 connector:

radioclkd2: Vcc-pin4/DTR, GND-pin5/GND, DCF-pin1/DCD
parse/generic: Vcc-pin7/RTS, GND-pin5/GND, DCF-pin2/RxD

While rewiring I thought it would be a nice idea to compare Frank’s parse driver with Jon’s SHM driver and fed the DCF77 signal to both pin1 (DCD) and pin2 RxD, using a drop of solder. +Vcc was connected to pin7 (RTS).

Using (sudo)  radioclkd2 -s iwait ttyS0:-dcd -d -v yielded DCF pulses and in ntp.conf I entered:

#PARSE Conrad RAW DCF77 (time1 0.2374)
server mode 5
fudge time1 0.2374 stratum 0 refid DCFa

#SHM driver (for use with radioclkd2)
fudge time1 0.0282 stratum 0 refid DCFb

Putting radioclkd2 into daemon mode (discarding the -d -v options), I restarted ntpd subsequently.  After a while ntpd synchronized to DCFb.  I monitored the behaviour of both ‘DCFa’ and ‘DCFb’, and found out that DCFb (i.e. radioclkd2) revealed less jitter.

Anyway, for whatever reason I thought about the ‘PPS’ option in conjunction with the parse driver (add 128 to mode number, i.e. server mode 5 -> server mode 133 in ntp.conf) would also be interesting.

Because I use LinuxPPS on ntp.remco.org with an Oncore UT+ timing receiver *and* now had a second PPS-source, i.e. the ‘DCF77-PPS’-signal connected to pin1 (DCD). I was curious how ntpd dealt with this ‘new PPS-peer’.

NB: Yes, yes, yes…. I know that DCF77 does not transmit data in the 59th second of a minute!

I gave it a try and activated a second PPS interface with: setserial /dev/ttyS1 hardpps or ppsldisc /dev/ttyS1 & (cf. LinuxPPS wiki, please read!):

remco@helium [/home/remco]> cat /sys/class/pps/pps1/{assert,clear}

The rising (assert) edge of the pulses are synchronized to UTC epochs by the PTB (Germany), and the pulse length (100 vs. 200 ms) is used to transmit information (see PTB site for an explanation of the DCF77 protocol).

The PPS-option for the GENERIC parse driver is activated by creating a /dev/refclockpps-* symlink to /dev/pps*, e.g.
(sudo) ln -s /dev/pps1 /dev/refclockpps-1.

In /etc/ntp.conf the following lines were inserted:

#ATOM driver22, rising edge, flag2 0
server minpoll 4 maxpoll 4
fudge flag2 0 flag3 1 stratum 0 refid PPSa

#PARSE driver8 Conrad RAW DCF77 (time1 0.2374)
server mode 133 prefer
fudge time1 0.2374 flag1 0 time2 0.0282 flag2 0 flag3 1 stratum 0 refid DCFa

I determined the time1 value empirically and took the time2 value from the empirically determined offset for radioclkd2. Perhaps some tweaking is necessary, but I consider it to be a good initial guess.

And… yes! After a while I obtained a sync for PPS(1), and observed lower jitters of PPS(1) than the ‘original’ DCF77-signal (DCFa) using a polling time of 16 seconds (minpoll 4). This means that one second in every 4th sample is missing, generating additional jitter. I did not experiment nor determined whether changing polling times to e.g. 16 or 64 seconds, i.e. [3*16+1*15]/64, is better or worse than 63/64. Although arithmetically identical, perhaps some software loop filters within ntpd have different time constants when using different polling times.

Because the jitter of the ‘DCF77-PPS’ is increased by the missing 59th second, perhaps it would be a suggestion that the PARSE driver8 in mode 133 inserts a time stamp in the 59th second of every minute, in the case that the DCF signal is fed to RxD and DCD simultaneously (might this be mode 20 for example? ; -). The omitting 59th time stamp may be derived from the 58th second or, for example, or the average from the last 5 seconds or so. LinuxPPS then ‘sees’  a time stamp every second, and my feeling says that the precision of the PARSE driver in RAWDCF mode (e.g. mode 5+128)  can be increased.

Feedback is highly appreciated.