| blob | 02f3960efe5bb241b6d491aaa86aa618acef38d7 |
3 <html>
5 <head>
9 </head>
11 <body>
13 <hr>
19 PPS device: <tt>/dev/refclockpps-<i>u</i></tt>; alternate PPS device (if not available via the serial port)
21 The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
22 <br>
23 <p>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 <a href="#clocklist">list below</a>).</p>
24 <p>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 a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p>
25 <p>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.</p>
28 <p>The ntpq program can read and display several clock variables. These hold the following information:</p>
29 <dl>
35 <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
40 </dl>
42 <dl>
47 </dl>
49 <p>Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.<br>
50 A note on the implementations:</p>
51 <ul>
52 <li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel <AT> ntp.org">kardel <AT> ntp.org</a>) are welcome as long as they work within Europe 8-).
54 <ul>
55 <li>RAWDCF variants
56 <p>These variants have been tested for correct 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 RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p>
58 <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
59 </ul>
60 </ul>
63 <ul>
65 <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50μs)</tt></b><br>
66 <br></p>
69 <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50μs)</tt></b><br>
71 <br></p>
74 <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</tt></b><br>
76 </p>
78 <p><b>Note:</b> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br>
79 <br></p>
82 <p><b><tt><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</tt></b><br>
83 <br></p>
87 <br></p>
91 <br></p>
95 <br></p>
98 <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br>
100 </p>
101 <p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
102 <p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p>
103 <p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
104 <p><b>Note:</b> mode 7 must not be used with Meinberg PCI cards; use <a href="#mode2">mode 2</a> instead.<br>
105 <br></p>
108 <p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></tt></b><br>
110 <br></p>
113 <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / <<1μs)</tt></b><br>
114 <br></p>
117 <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1μs) (no kernel support yet)</tt></b><br>
120 <br></p>
124 <br></p>
127 <p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></tt></b><br>
129 <br></p>
133 <br></p>
137 <br></p>
141 <br></p>
145 <br></p>
149 <br></p>
152 <p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br>
153 </p>
154 <p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p>
156 <br></p>
159 <br></p>
161 </ul>
162 <p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
164 <p>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.</p>
165 <p>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.</p>
166 <p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM 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). Synchronization ceases when reception of the DCF77 signal deteriorates, since 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. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p>
167 <p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). 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.
168 </p>
170 </h4>
172 <p>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.</p>
174 <p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the <code>ntpq cv</code> command.<br>
175 Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data
176 and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on
177 a specific clock association as shown below.
178 </p>
180 <pre>
181 ntpq> as
182 ind assID status conf reach auth condition last_event cnt
183 ===========================================================
187 </pre>
188 <p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p>
189 <pre>
190 ntpq> raw
191 Output set to raw
192 </pre>
194 <pre>
196 </pre>
198 <pre>
200 clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1,
201 fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status,
202 refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,
203 meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,
206 </pre>
207 <p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
208 <pre>
210 refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,
211 gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],
214 </pre>
215 <p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
216 <pre>
217 status=0x0003,
218 refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION;
219 PPS SIGNAL; POSITION)",
225 kardel RELEASE_20060805_A",
231 UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s,
241 </pre>
243 <dl>
245 <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type.
247 <dd>
248 If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning).
249 <dd>
250 If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation.
252 <dd>The stratum for this reference clock.
254 <dd>The refid for this reference clock.
255 </dl>
256 <dl>
265 <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-)
266 </dl>
267 <span style="font-weight: bold;">Note about auxiliary Sun STREAMS modules (SunOS and Solaris):</span><br>
268 <dl>
269 <dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used.
270 </dl>
272 <p>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 <a href="../parsenew.html">making PARSE clocks</a>.</p>
275 <hr>
277 </body>
279 </html>