Configuring Parse Refclocks
Configuring a Meinberg GPS167BGT
Harlan uses the Yost serial connector scheme
ports get Yost DCE adapters on them. Note that the
ports do not provide PPS, while the
ports provide PPS on pin 1.
I used modes 7/135 for these ports. Note that mode 135 includes PPS processing, so the ATOM driver should not be used in this case. If mode 7 is used instead, one has the option of also configuring the ATOM refclock to read a PPS pulse.
Configuring a Meinberg DCF77-C51
The C51 is connected via a modem cable (straight serial cable). Harlan used a Yost DTE adapter.
server 127.127.8.0 mode 2
fudge 127.127.8.0 time1 <delay at your place>
The time1 value defaults to 10. There is also a RAWDCF cable, which would apparently use mode 14 or 16.
Configuring a generic raw DCF receiver
This section covers DCF receivers which convert the AM carrier reduction into an electrical pulse without any data processing.
The only input needed by ntpd is the 100ms/200ms pulse from the receiver connected to a serial port's
(Receive Data, pin #2 on 9 pin connectors, pin #3 on 25 pin connectors) and signal ground (
, pin #5 on 9 pin connectors, pin #7 on 25 pin connectors). However, the receiver may not provide the correct signal levels or be able to provide enough current to drive the serial port input. According to the RS232 specification the RXD signal levels should be between +3V and +12V for the duration of the pulse and between -3V and -12V otherwise, however I found on all the serial ports I tried that inputting TTL levels also works.
Note 1: TODO: Describe how some receivers may be powered by appropriately setting serial port status signals.
Note 2: Although using USB to serial adapters should work, the achievable accuracy will be lower than with a genuine serial port.
Testing the setup
The ntp package provides the programs
for this purpose, however my experience with these utilities is mixed. At the very least in
with a correctly wired connection you should see a new bit being received each second, even if no valid data can be decoded.
By default ntp is built without
support for raw DCF clocks, so before (re-)building it you need to run
The minimal ntp.conf configuration (for the first clock) is:
server 127.127.8.0 mode 5
And as usual you need to create a symbolic link to the real device file
cassiopeia:/dev # ln -s ttyS1 refclock-0
cassiopeia:/dev # ls -l refclock-0
lrwxrwxrwx 1 root root 5 2010-07-23 16:39 refclock-0 -> ttyS1
After starting ntpd the new refclock should be listed as
if you type
harry@cassiopeia:~> ntpq -p
remote refid st t when poll reach delay offset jitter
LOCAL(0) .LOCL. 10 l 9 64 1 0.000 0.000 0.001
ptbtime3.ptb.de .PTB. 1 u 5 64 1 60.137 4.912 0.001
GENERIC(0) .DCFa. 3 l - 64 0 0.000 0.000 0.000
The DCF parser needs at least one full minute (e.g. from 23:29:00 to 23:30:00) to read the DCF data, so it will take longer than for other servers for any "reach" indication. When the first full minute after ntpd start is reached the ntp logfile will show for the this incomplete minute something like this:
30 Jul 23:29:00 ntpd: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 48 bits
30 Jul 23:29:00 ntpd: PARSE receiver #0: interval for following error message class is at least 00:01:00
30 Jul 23:29:00 ntpd: PARSE receiver #0: FAILED TIMECODE: "-#----#--##--#-R-DMLs--48---p124-12P1------2---" (check receiver configuration / wiring)
If reception is good, there will be no (or few) other entries of this kind and after one full minute and the next poll
should indicate a nonzero
line above indicates a mix of zeros and ones being received (e.g. by not starting with "-----------" or "##########"). That is what good reception looks like. If you see that only zeros or only ones are received, your electrical input signal is likely to be inverted.
The time offset can be adjusted by adding something like
fudge 127.127.8.0 time1 0.246
. However, without this fudge, the raw DCF driver uses an offset of 0.258, so the above example creates an offset of -0.012 relative to the default.