Reference ID: <tt>NIST | USNO | PTB | WWVB</tt><br>
Driver ID: <tt>ACTS_MODEM</tt><br>Serial Port: <tt>/dev/acts<i>u</i></tt>; 9600 baud, 8-bits, no parity<br>
Features: <tt>tty_clk</tt><br>
- Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control</p>
+ Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control and a dial-out (cua) device.</p>
<h4>Description</h4>
- <p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available.</p>
- <p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delay, which can be 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p>
+ <p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p>
+ <p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p>
<p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p>
- <p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done using <tt>ntpdc</tt>, either manually or via a cron job. In auto mode (0) <tt>flag1</tt> is set automatically at each poll event. In backup mode (1) <tt>flag1</tt> is set automatically at each poll event, but only if the prefer peer is unreachable. </p>
- <p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpdc</tt>.</p>
- <p>The driver is transparent to the message format of each modem time service and Spectracom radio. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p>
- <p>Ordinarily, the serial port is connected to a modem; however, if fudge <tt>flag3</tt> is set, it can be connected directly to a device or another computer for testing or calibration. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p>
- <p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. Ordinarily, the poll interval follows the system poll interval, but not less than the minpoll specification. should ramp up over time to over a day.</p>
- <p>The behavior of the clock selection algorithm is modified when this driver is in use. The algorithm is designed so that this driver will be selected only when the prefer peer is unreachable or unspecified. This can be overridden by assigning this driver as the prefer peer, in which case only this driver will be selected for synchronization and all other discipline sources will be ignored.</p>
+ <p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpdc</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p>
+ <p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpdc</tt>.</p>
+ <p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p>
+ <p>Ordinarily, the serial port is connected to a modem; however, if fudge <tt>flag3</tt> is set, it can be connected directly to a Spectracom WWV or GPS radio for testing or calibration. The Spectracom radio can be connected via a modem if the radio is connfigured to send time codes continuoulsly at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p>
+ <p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p>
<h4>US Phone Numbers and Formats</h4>
<p>Note: Phone numbers include the entire Hayes modem command, including the <tt>ATDT</tt> and other control codes as may be necessary. For most cases only the <tt>ATDT</tt> may be necessary.</p>
<p><a href=http://www.boulder.nist.gov/timefreq>National Institute of Science and Technology (NIST)</a></p>
</p>
<p><a href=http://tycho.usno.navy.mil/modem_time.html>Data Format</a> (two lines, repeating at one-second intervals)</p>
<p><tt>jjjjj nnn hhmmss UTC</tt></p>
- <p>* on-time character<br>
+ <p>* on-time character for previous timecode message<br>
jjjjj modified Julian day number (not used)<br>
nnn day of year<br>
hhmmss second of day
<p><a href=http://www.spectracomcorp.com>Spectracom GPS and WWVB Receivers</a></p>
<p>If a modem is connected to a Spectracom receiver, this driver will call it and retrieve the time in one of two formats, 0 and 2. Ordinarily, the receiver requires a <tt>T</tt> in order to return the timecode. As this driver does not send data via the modem, it must either be configured in continuous mode or be polled by another local driver.</p>
<h4>Monitor Data</h4>
- <p>Every received timecode is written as-is to the <tt>clockstats</tt> file.</p>
+ <p>The received timecode is written as-is to the <tt>clockstats</tt> file along with the Hayes connection and hangup commands and result codes.</p>
<h4>Fudge Factors</h4>
<dl>
<dt><tt>time1 <i>time</i></tt>
<p>To work well, the driver needs a shortwave receiver with good audio response at 100 Hz. Most shortwave and communications receivers roll off the audio response below 250 Hz, so this can be a problem, especially with receivers using DSP technology, since DSP filters can have very fast rolloff outside the passband. Some DSP transceivers, in particular the ICOM 775, have a programmable low frequency cutoff which can be set as low as 80 Hz. However, this particular radio has a strong low frequency buzz at about 10 Hz which appears in the audio output and can affect data recovery under marginal conditions. Although not tested, it would seem very likely that a cheap shortwave receiver could function just as well as an expensive communications receiver.</p>
<h4>Autotune</h4>
<p>The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a serial port using a level converter such as the CT-17.</p>
- <p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given below. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. A missing <tt>mode</tt> keyword or a zero argument leaves the interface disabled.</p>
+ <p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given on the <a href="../audio.html">Reference Clock Audio Drivers</a> page. A missing <tt>mode</tt> keyword or a zero argument leaves the interface disabled.</p>
<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will activate the autotune function and tune the radio to each operating frequency in turn while attempting to acquire minute sync from either WWV or WWVH. However, the driver is liberal in what it assumes of the configuration. If the <tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus or radio is inoperative, the driver quietly gives up with no harm done.</p>
<p>Once acquiring minute sync, the driver operates as described above to set the clock. However, during seconds 59, 0 and 1 of each minute it tunes the radio to one of the five broadcast frequencies to measure the sync pulse and data pulse amplitudes and SNR and update the signal metric. Each of the five frequencies are probed in a five-minute rotation to build a database of current propagation conditions for all signals that can be heard at the time. At the end of each probe a mitigation procedure scans the database and retunes the radio to the best frequency and station found. For this to work well, the radio should be set for a fast AGC recovery time. This is most important while tracking a strong signal, which is normally the case, and then probing another frequency, which may have much weaker signals.</p>
<p>Reception conditions for each frequency and station are evaluated according to the signal metric, which uses the minute sync pulse amplitude and SNR and data subcarrier amplitude and SNR. The minute pulse is evaluated at second 0, while the data pulse is evaluated at second 1. In principle, the data pulse in second 58 is usable, but the AGC in most radios is not fast enough for a reliable measurement.</p>
<p>An example timecode is:</p>
<p><tt>0 2000 006 22:36:00 S +3 1 115 WV20 86 5 66.4 1024</tt></p>
<p>Here the clock has been set and no alarms are raised. The year, day and time are displayed along with no leap warning, standard time and DUT +0.3 s. The clock was set on the last minute, the AGC is safely in the middle ot the range 0-255, and the receiver is tracking WWV on 20 MHz. Good receiving conditions prevail, as indicated by the metric 86 and 5 bit errors during the last minute. The current frequency is 66.4 PPM and the averaging interval is 1024 s, indicating the maximum precision available.</p>
- <h4>Modes</h4>
- <p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code in decimal. A missing or zero argument disables the CI-V interface. Following are the ID select codes for the known radios. These codes are for 9600 baud rate; for 1200 baud rate add 128.</p>
- <table width="100%" cols="6">
- <tr>
- <td>Radio</td>
- <td>Hex</td>
- <td>Decimal</td>
- <td>Radio</td>
- <td>Hex</td>
- <td>Decimal</td>
- </tr>
- <tr>
- <td>706</td>
- <td>0x4e</td>
- <td>78</td>
- <td>775</td>
- <td>0x46</td>
- <td>68</td>
- </tr>
- <tr>
- <td>706MKIIG</td>
- <td>0x58</td>
- <td>88</td>
- <td>781</td>
- <td>0x26</td>
- <td>38</td>
- </tr>
- <tr>
- <td>725</td>
- <td>0x28</td>
- <td>40</td>
- <td>970</td>
- <td>0x2e</td>
- <td>46</td>
- </tr>
- <tr>
- <td>726</td>
- <td>0x30</td>
- <td>48</td>
- <td>R71</td>
- <td>0x1A</td>
- <td>26</td>
- </tr>
- <tr>
- <td>735</td>
- <td>0x04</td>
- <td>4</td>
- <td>R72</td>
- <td>0x32</td>
- <td>50</td>
- </tr>
- <tr>
- <td>751</td>
- <td>0x1c</td>
- <td>28</td>
- <td>R7000</td>
- <td>0x08</td>
- <td>8</td>
- </tr>
- <tr>
- <td>756PROII</td>
- <td>0x64</td>
- <td>100</td>
- <td>R8500</td>
- <td>0x4a</td>
- <td>74</td>
- </tr>
- <tr>
- <td>761</td>
- <td>0x1e</td>
- <td>30</td>
- <td>R9000</td>
- <td>0x2a</td>
- <td>42</td>
- </tr>
- <tr>
- <td>765</td>
- <td>0x2c</td>
- <td>44</td>
- <td></td>
- <td></td>
- <td></td>
- </tr>
- </table>
- <h4>Fudge Factors</h4>
- <dl>
+ <h4>Fudge Factors</h4>
+ <dl>
<dt><tt>time1 <i>time</i></tt>
<dd>Specifies the propagation delay for WWV (40:40:49.0N 105:02:27.0W), in seconds and fraction, with default 0.0.
<dt><tt>time2 <i>time</i></tt>
<dt><tt>flag4 0 | 1</tt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.
</dl>
- <hr>
+ <hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<h4>Performance and Horror Stories</h4>
<p>The <font face="symbol">m</font>-law companded data format allows considerable latitude in signal levels; however, an automatic gain control (AGC) function is implemented to further compensate for varying input signal levels and to avoid signal distortion. For proper operation, the IRIG signal source should be configured for analog signal levels, NOT digital TTL levels.</p>
<p>The accuracy of the system clock synchronized to the IRIG-B source with this driver and the <tt>ntpd</tt> daemon is 10-20 <font face="symbol">m</font>s with a Sun UltraSPARC II running Solaris 2.6 and maybe twice that with a Sun SPARC IPC running SunOS 4.1.3. Be however acutely aware that the accuracy with Solaris 2.8 and presumably beyond has seriously degraded to the order of several milliseconds. The Sun kernel driver has a sawtooth modulation with amplitude over 5 ms peak-peak and period 5.5 s. The crafty IRIG driver uses a transverse filter to remove the modulation and something called a botttom-fisher to remove incidental positive spikes especially prevalent with Sun Blade 1000 and possibly other systems. The result is nominal accuracy and jitter something less than 0.5 ms, but the this is still far inferior to the performance with older systems.</p>
- <p>The processor resources consumed by the daemon can be significant, ranging from about 1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC IPC. However, the overall timing accuracy is limited by the resolution and stability of the CPU clock oscillator and the interval between clock corrections, which is 64 s with this driver. This performance, while probably the best that can be achieved by the daemon itself, can be improved with assist from the PPS discipline as described elsewhere in this documentation.</p>
- <h4>Monitor Data</h4>
+ <p>The processor resources consumed by the daemon can be significant, ranging from about 1.2 percent on the faster UltraSPARC II to 38 percent on the slower SPARC IPC. However, the overall timing accuracy is limited by the resolution and stability of the CPU clock oscillator and the interval between clock corrections, which is 64 s with this driver. This performance, while probably the best that can be achieved by the daemon itself, can be improved with assist from the PPS discipline as described elsewhere in this documentation.</p>
+ <h4>Autotune</h4>
+ <p>The driver includes provisions to automatically tune the radio in response to changing radio propagation conditions throughout the day and night. The radio interface is compatible with the ICOM CI-V standard, which is a bidirectional serial bus operating at TTL levels. The bus can be connected to a serial port using a level converter such as the CT-17.</p>
+ <p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given on the <a href="../audio.html">Reference Clock Audio Drivers</a> page. A missing <tt>mode</tt> keyword or a zero argument leaves the interface disabled.</p>
+ <p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will activate the autotune function and tune the radio to each operating frequency in turn while attempting to acquire minute sync from CHU. However, the driver is liberal in what it assumes of the configuration. If the <tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus or radio is inoperative, the driver quietly gives up with no harm done.</p>
+ <h4>Monitor Data</h4>
The timecode format used for debugging and data recording includes data helpful in diagnosing problems with the IRIG signal and codec connections. With debugging enabled (-d on the ntpd command line), the driver produces one line for each timecode in the following format:
<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5 3094572411.00027</tt></p>
<p>The first field containes the error flags in hex, where the hex bits are interpreted as below. This is followed by the IRIG status indicator, year of century, day of year and time of day. The status indicator and year are not produced by some IRIG devices. Following these fields are the carrier amplitude (0-8100), codec gain (0-255), field phase (0-79), time constant (2-20), modulation index (0-1), carrier phase error (0±0.5) and carrier frequency error (PPM). The last field is the on-time timestamp in NTP format. The fraction part is a good indicator of how well the driver is doing. With an UltrSPARC 30, this is normally within a few tens of microseconds relative to the IRIG-B signal and within a few hundred microseconds with IRIG-E.</p>
projects / thirdparty / ntp.git / commitdiff
