Configuring Parse Refclocks

Related Topics:: ParseRefclockUsers

Configuring a Meinberg GPS167BGT

Harlan uses the Yost serial connector scheme.

The COMx and TxD ports get Yost DCE adapters on them. Note that the COM ports do not provide PPS, while the TxDx 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.

Minimum ntpd.conf:

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.

Electrical connection

The only input needed by ntpd is the 100ms/200ms pulse from the receiver connected to a serial port's RXD (Receive Data, pin #2 on 9 pin connectors, pin #3 on 25 pin connectors) and signal ground ( SG, 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 parseutil/testdcf and parseutil/dcfd for this purpose, however my experience with these utilities is mixed. At the very least in testdcf with a correctly wired connection you should see a new bit being received each second, even if no valid data can be decoded.

Configuring ntp

By default ntp is built without support for raw DCF clocks, so before (re-)building it you need to run

./configure --enable-RAWDCF

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 GENERIC 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[15791]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 48 bits
30 Jul 23:29:00 ntpd[15791]: PARSE receiver #0: interval for following error message class is at least 00:01:00
30 Jul 23:29:00 ntpd[15791]: 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 ntpq -p should indicate a nonzero reach. The FAILED TIMECODE 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

to ntp.conf. 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.