The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see list below).
The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as an configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.
CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.
The use of the PPS option requires receivers with an accuracy of better than 1ms.
The ntpq program can read and display several clock variables. These hold the following information: refclock_time is the local time with the offset to UTC (format HHMM). The currently active receiver flags are listed in refclock_status. Additional feature flags of the receiver are optionally listed in parentheses. The actual time code is listed in timecode. A qualification of the decoded time code format is following in refclock_format. The last piece of information is the overall running time and the accumulated times for the clock event states in refclock_states. If PPS information is present additional variables are available. refclock_ppstime lists then the PPS timestamp and refclock_ppsskew lists the difference between RS232 derived timestamp and the PPS timestamp.
Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.
A note on the implementations:
Verified implementations are:
These variants are tested for the decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.
These implementations are verified by the Meinberg people themselves and I have access to one of these clocks.
The pictures below refer to the respective clock and were taken from the vendors' web pages. They are linked to the respective vendors.
Meinberg PZF5xx receiver family (FM demodulation/TCXO / 50μs)
Meinberg PZF5xx receiver family (FM demodulation/OCXO / 50μs)
Meinberg DCF C51 receiver and similar (AM demodulation / 4ms)
This mode expects the Meinberg standard time string format with 9600/7E2.
Note: mode 2 must also be used for Meinberg PCI cards under Linux, e.g. GPS170PCI or PCI511. Please note the Meinberg Linux driver must be installed. That driver emulates a refclock device to let ntpd be able to access those cards. For details please refer to the README file which comes with the Meinberg driver package.
ELV DCF7000 (sloppy AM demodulation / 50ms)
Walter Schmid DCF receiver Kit (AM demodulation / 1ms)
RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)
RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)
Meinberg GPS16x/GPS17x receivers (GPS / <<1μs)
This mode expects either the Uni Erlangen time string format or the Meinberg standard time string format at 19200/8N1.
The Uni Erlangen format should be used preferably. Newer Meinberg GPS receivers can be configured to transmit that format, for older devices there may be a special firmware version available.
In this mode there's also some data communication which reads additonal GPS receiver status information. However, this requires a point-to-point connection. Mode 18 should be used instead if the device is accessed by a multidrop connection.
Note: mode 7 must not be used with Meinberg PCI cards, use mode 2 instead.
Trimble SVeeSix GPS receiver TAIP protocol (GPS / <<1μs)
Trimble SVeeSix GPS receiver TSIP protocol (GPS / <<1μs) (no kernel support yet)
Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support
Diem's Computime Radio Clock
RAWDCF receiver (DTR=high/RTS=low)
WHARTON 400A Series Clocks with a 404.2 Serial Interface
RAWDCF receiver (DTR=low/RTS=high)
VARITEXT Receiver (MSF)
Meinberg GPS16x/GPS17x receivers (GPS / <<1μs)
This mode works without additional data communication (version, GPS status etc.) and thus should be used with multi drop, heterogeneous multi client operation.
Note: mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.
Actual data formats and setup requirements of the various clocks can be found in NTP PARSE clock data formats.
The reference clock support software carefully monitors the state transitions of the receiver. All state changes and exceptional events (such as loss of time code transmission) are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.
PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.
The raw DCF77 pulses can be fed via a level converter directly into Pin 3 (Rx) of the Sun's serial port. The telegrams are decoded and used for synchronization. AM DCF77 receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Upon bad signal reception of DCF77, synchronization ceases, as no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. For transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.
In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually applied via the CD pin (8) on serial devices. To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used.
For PPS to be used you MUST add 128 to the mode parameter.
If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.
Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the ntpq cv command.
Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data
and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on
a specific clock association like this:
ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 19556 9154 yes yes none falsetick reachable 5 2 19557 9435 yes yes none candidat clock expt 3 3 19558 9714 yes yes none pps.peer reachable 1 ntpq> raw Output set to raw ntpq> cv 19557 clock_var_list assID=19557 status=0x0000, clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1,fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status,refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]" ntpq> cv 19557 refclock_status,refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5] status=0x0003, refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION)", refclock_format="Meinberg GPS Extended", refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%); running time: 21:21:39", refclock_id="GPS", refclock_iomode="normal", refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49 kardel RELEASE_20060805_A", meinberg_gps_status="[0x0000] <OK>", gps_utc_correction="current correction 14 sec, last correction on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000", gps_message="/PFU3SOP-4WG14EPU0V1KA", meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000) UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s, disconnect time 0000-00-00 00:00:00.0000000 (+0000) ", gps_tot_51="week 1400 + 3 days + 42300.0000000 sec", gps_tot_63="week 1400 + 3 days + 42294.0000000 sec", gps_t0a="week 1400 + 5 days + 71808.0000000 sec", gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK", gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS", gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK", gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK", gps_cfg[5]="[0x9] BLOCK II" ntpq>
Currently raw output is needed because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.
The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see making PARSE clocks
Additional Information