diff options
Diffstat (limited to 'html/drivers')
| -rw-r--r-- | html/drivers/driver1.html | 21 | ||||
| -rw-r--r-- | html/drivers/driver10.html | 92 | ||||
| -rw-r--r-- | html/drivers/driver11.html | 112 | ||||
| -rw-r--r-- | html/drivers/driver18.html | 4 | ||||
| -rw-r--r-- | html/drivers/driver19.html | 96 | ||||
| -rw-r--r-- | html/drivers/driver20.html | 60 | ||||
| -rw-r--r-- | html/drivers/driver22.html | 103 | ||||
| -rw-r--r-- | html/drivers/driver27.html | 2 | ||||
| -rw-r--r-- | html/drivers/driver28.html | 65 | ||||
| -rw-r--r-- | html/drivers/driver29.html | 324 | ||||
| -rw-r--r-- | html/drivers/driver34.html | 172 | ||||
| -rw-r--r-- | html/drivers/driver36.html | 123 | ||||
| -rw-r--r-- | html/drivers/driver4.html | 162 | ||||
| -rw-r--r-- | html/drivers/driver6.html | 58 | ||||
| -rw-r--r-- | html/drivers/driver7.html | 243 | ||||
| -rw-r--r-- | html/drivers/driver8.html | 21 | ||||
| -rw-r--r-- | html/drivers/driver9.html | 101 | ||||
| -rw-r--r-- | html/drivers/mx4200data.html | 1074 |
18 files changed, 2118 insertions, 715 deletions
diff --git a/html/drivers/driver1.html b/html/drivers/driver1.html index afd85d211faf..9c58265c908b 100644 --- a/html/drivers/driver1.html +++ b/html/drivers/driver1.html @@ -17,24 +17,9 @@ Reference ID: <tt>LCL</tt><br> Driver ID: <tt>LOCAL</tt></p> <h4>Description</h4> - <p>This driver is intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available. It allows a designated time server to act as a primary server to provide synchronization to other clients on the network. Pick a machine that has a good clock oscillator (Digital machines are good, Sun machines are not) and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast (not multicast) mode to distribute time.</p> - <p>Another application for this driver is if a particular server clock is to be used as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would configure this driver at a stratum greater than any other likely sources of time (say 3 or 4) to prevent the server taking over when legitimate sources are still available.</p> - <p>A third application for this driver is when an external discipline source is available, such as the NIST <tt>lockclock</tt> program, which synchronizes the local clock via a telephone modem and the NIST Automated Computer Time Service (ACTS), or the Digital Time Synchronization Service (DTSS), which runs on DCE machines. In this case the stratum should be set at zero, indicating a bona fide stratum-1 source. In the case of DTSS, the local clock can have a rather large jitter, depending on the interval between corrections and the intrinsic frequency error of the clock oscillator. In extreme cases, this can cause clients to exceed the 128-ms slew window and drop off the NTP subnet.</p> - <p>In the case where a NTP time server is synchronized to some device or protocol that is not external to the NTP daemon itself, some means should be provided to pass such things as error and health values to the NTP daemon for dissemination to its clients. If this is not done, there is a very real danger that the device or protocol could fail and with no means to tell NTP clients of the mishap. When ordinary Unix system calls like <tt>adjtime()</tt> are used to discipline the kernel clock, there is no obvious way this can be done without modifying the code for each case. However, when a modified kernel with the <tt>ntp_adjtime()</tt> system call is available, that routine can be used for the same purpose as the <tt>adjtime()</tt> routine and in addition provided with the estimated error, maximum error, and leap-indicator values. This is the preferred way to synchronize the kernel clock and pass information to the NTP clients.</p> - <p>In the default mode the behavior of the clock selection algorithm is modified when this driver is in use. The algorithm is designed so that this driver will never be selected unless no other discipline source is available. This can be overridden with the <tt>prefer</tt> keyword of the <tt>server</tt> configuration command, in which case only this driver will be selected for synchronization and all other discipline sources will be ignored. This behavior is intended for use when an external discipline source controls the system clock. See the <a href="../prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page for a detailed description of the exact behavior.</p> - <p>The stratum for this driver is set at 5 by default, but can be changed by the <tt>fudge</tt> configuration command and/or the <tt>ntpdc</tt> utility. The reference ID is <tt>LCL</tt> by default, but can be changed using the same mechanisms. <b>*NEVER*</b> configure this driver to operate at a stratum which might possibly disrupt a client with access to a bona fide primary server, unless the local clock oscillator is reliably disciplined by another source. <b>*NEVER NEVER*</b> configure a server which might devolve to an undisciplined local clock to use multicast mode.</p> - <p>This driver provides a mechanism to trim the local clock in both time and frequency, as well as a way to manipulate the leap bits. The <tt>fudge time1</tt> parameter adjusts the time (in seconds) and the <tt>fudge time2</tt> parameter adjusts the frequency (in parts per million). Both parameters are additive and operate only once; that is, each command (as from <tt>ntpdc</tt>) adds signed increments in time or frequency to the nominal local clock time and frequency.</p> - <h4>Operation with an External Reference Source</h4> - <p>There are special provisions for this driver to operate in conjunction with an external reference source, such as the <tt>LOCKCLOCK</tt> scheme used by the NIST time servers. In such schemes the system clock is disciplined by a source external to NTP, in the <tt>LOCKCLOCK</tt> case an ACTS telephone modem. To support <tt>LOCKCLOCK</tt> the NTP distribution should be built with the <tt>--enable-nist</tt> parameter in the configuration phase of the build procedure. This changes the system behavior as follows:</p> - <ol> - <li>The system clock is not disciplined in any way other than to call the <tt>ntp_adjtime()</tt> system call to obtain the kernel leap code, which becomes the driver leap code and. If the kernel leap code is 11 (not synchronized), the driver stratum is infinity; otherwise the stratum is set by the <tt>stratum</tt> subcommand on the <tt>fudge</tt> command applying to the driver. - <li>The NTP algorithms operate in the normal fashion with this driver and possibly other drivers and servers; however, the local clock driver as the <tt>prefer</tt> peer will always be selected, even if declared falseticker by the selection algorithm or fails to survive the clustering algorithm. - <li>If the driver leap code is 11, the system leap code is 11, system stratum infinity and system reference identifier <tt>DOWN</tt>. This provides a definitive status condition to dependent clients. - </ol> - <p>The local clock driver should be configured something like this:</p> - <p><tt>server 127.127.1.1 prefer</tt></p> - <p><tt>fudge 127.127.1.1 stratum 0 refid NIST</tt></p> - <p>The <tt>prefer</tt> keyword forces the driver to discipline the clock, even if other servers are configured and running correctly. This is convenient when a number of servers watch each other for monitoring and statistics gathering. In particular, the <tt>peerstats</tt> data and <tt>sysstats</tt> data can be collected at each server, aggregated for daily or weekly reports and sent by electric mail to a monitoring site. In addition, the full suite of cryptographic authentication algorithms is avialable to other servers and dependent clients.</p> + <p>Not: This driver is not recommended for new installations. A much more flexible replacement is available in the form of orphan mode described on the <a href="../assoc.html">Association Management page</a>.</p> + <p>This driver is intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available. It allows a designated time server to act as a primary server to provide synchronization to other clients on the network. Pick a machine that has a good clock oscillator (Digital machines are good, Sun machines are not) and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast mode to distribute time.</p> + <p>Another application for this driver is if a particular server clock is to be used as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would usually, but not necessarily, configure this driver at a stratum greater than any other likely sources of time, such as the default 5 for this driver, to prevent this driver taking over when legitimate sources elsewher in the network are available. To further protect the Internet infrastructure from accidental or malicious exposure to this driver, the driver is desabled if another source is available and operating.</p> <h4>Monitor Data</h4> <p>No <tt>filegen clockstats</tt> monitor data are produced by this driver.</p> <h4>Fudge Factors</h4> diff --git a/html/drivers/driver10.html b/html/drivers/driver10.html index 97b0495d59e0..20391d3b780d 100644 --- a/html/drivers/driver10.html +++ b/html/drivers/driver10.html @@ -2,52 +2,52 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>Austron 2200A/2201A GPS Receivers</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> + <head> + <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> + <title>Austron 2200A/2201A GPS Receivers</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>Austron 2200A/2201A GPS Receivers</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.10.<i>u</i><br> - Reference ID: <tt>GPS</tt><br> - Driver ID: <tt>GPS_AS2201</tt><br> - Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> - Features: <tt>tty_clk</tt></p> - <h4>Description</h4> - <p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver. For operation with multiple computers, it requires the <tt>ppsclock</tt> streams module described in the <a href="../ldisc.html">Line Disciplines and Streams Modules</a> page. The streams module requires a gadget box and 1-PPS level converter, such as described in the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p> - <p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p> - <p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p> - of the ntp3 distribution. - <h4>Monitor Data</h4> - <p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Set for computers that listen-only. - <dt><tt>flag3 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag4 0 | 1</tt> - <dd>Enable verbose <tt>clockstats</tt> recording if set. - </dl> - <h4>Additional Information</h4> - <p><a href="../refclock.html">Reference Clock Drivers</a></p> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> + <body> + <h3>Austron 2200A/2201A GPS Receivers</h3> + <hr> + <h4>Synopsis</h4> + <p>Address: 127.127.10.<i>u</i><br> + Reference ID: <tt>GPS</tt><br> + Driver ID: <tt>GPS_AS2201</tt><br> + Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> + Features: <tt>tty_clk</tt></p> + <h4>Description</h4> + <p>This driver supports the Austron 2200A/2201A GPS/LORAN Synchronized Clock and Timing Receiver connected via a serial port. It supports several special features of the clock, including the Input Buffer Module, Output Buffer Module, IRIG-B Interface Module and LORAN Assist Module. It requires the RS232 Buffered Serial Interface module for communication with the driver.</p> + <p>For use with a single computer, the receiver can be connected directly to the receiver. For use with multiple computers, one of them is connected directly to the receiver and generates the polling messages. The other computers just listen to the receiver output directly or through a buffer amplifier. For computers that just listen, <tt>fudge flag2</tt> must be set and the <tt>ppsclock </tt>streams module configured on each of them.</p> + <p>This receiver is capable of a comprehensive and large volume of statistics and operational data. The specific data collection commands and attributes are embedded in the driver source code; however, the collection process can be enabled or disabled using the flag4 flag. If set, collection is enabled; if not, which is the default, it is disabled. A comprehensive suite of data reduction and summary scripts is in the ./scripts/stats directory</p> + of the ntp3 distribution. + <h4>Monitor Data</h4> + <p>When enabled by the <tt>flag4</tt> fudge flag, every received timecode is written as-is to the <tt>clockstats</tt> file.</p> + <h4>Fudge Factors</h4> + <dl> + <dt><tt>time1 <i>time</i></tt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. + <dt><tt>time2 <i>time</i></tt> + <dd>Not used by this driver. + <dt><tt>stratum <i>number</i></tt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + <dt><tt>refid <i>string</i></tt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. + <dt><tt>flag1 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag2 0 | 1</tt> + <dd>Set for computers that listen-only. + <dt><tt>flag3 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag4 0 | 1</tt> + <dd>Enable verbose <tt>clockstats</tt> recording if set. + </dl> + <h4>Additional Information</h4> + <p><a href="../refclock.html">Reference Clock Drivers</a></p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html>
\ No newline at end of file diff --git a/html/drivers/driver11.html b/html/drivers/driver11.html index b36f7f353984..e7c370a5920c 100644 --- a/html/drivers/driver11.html +++ b/html/drivers/driver11.html @@ -2,30 +2,28 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>Arbiter 1088A/B GPS Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> + <head> + <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> + <title>Arbiter 1088A/B GPS Receiver</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>Arbiter 1088A/B GPS Receiver</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.11.<i>u</i><br> - Reference ID: <tt>GPS</tt><br> - Driver ID: <tt>GPS_ARBITER</tt><br> - Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> - Features: <tt>tty_clk</tt></p> - <h4> - <p>Description</p> - </h4> - <p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p> - <p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p> - <p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p> - <p>Format <tt>B5</tt> (24 ASCII printing characters):</p> - <pre><cr><lf>i yy ddd hh:mm:ss.000bbb + <body> + <h3>Arbiter 1088A/B GPS Receiver</h3> + <hr> + <h4>Synopsis</h4> + <p>Address: 127.127.11.<i>u</i><br> + Reference ID: <tt>GPS</tt><br> + Driver ID: <tt>GPS_ARBITER</tt><br> + Serial Port: <tt>/dev/gps<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> + Features: <tt>tty_clk</tt></p> + <h4>Description</h4> + <p>This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The claimed accuracy of this clock is 100 ns relative to the PPS output when receiving four or more satellites.</p> + <p>The receiver should be configured before starting the NTP daemon, in order to establish reliable position and operating conditions. It does not initiate surveying or hold mode. For use with NTP, the daylight savings time feature should be disables (<tt>D0</tt> command) and the broadcast mode set to operate in UTC (<tt>BU</tt> command).</p> + <p>The timecode format supported by this driver is selected by the poll sequence <tt>B5</tt>, which initiates a line in the following format to be repeated once per second until turned off by the <tt>B0</tt> command.</p> + <p>Format <tt>B5</tt> (24 ASCII printing characters):</p> + <pre><cr><lf>i yy ddd hh:mm:ss.000bbb on-time = <cr> i = synchronization flag (' ' = locked, '?' = unlocked) @@ -34,10 +32,10 @@ ddd = day of year hh:mm:ss = hours, minutes, seconds .000 = fraction of second (not used) bbb = tailing spaces for fill</pre> - <p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p> - <p>The time quality character is encoded in IEEE P1344 standard:</p> - <p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p> - <pre>0 clock locked, maximum accuracy + <p>The alarm condition is indicated by a '?' at i, which indicates the receiver is not synchronized. In normal operation, a line consisting of the timecode followed by the time quality character (TQ) followed by the receiver status string (SR) is written to the clockstats file.</p> + <p>The time quality character is encoded in IEEE P1344 standard:</p> + <p>Format <tt>TQ</tt> (IEEE P1344 estimated worst-case time quality)</p> + <pre>0 clock locked, maximum accuracy F clock failure, time not reliable 4 clock unlocked, accuracy < 1 us 5 clock unlocked, accuracy < 10 us @@ -47,41 +45,41 @@ F clock failure, time not reliable 9 clock unlocked, accuracy < 100 ms A clock unlocked, accuracy < 1 s B clock unlocked, accuracy < 10 s</pre> - <p>The status string is encoded as follows:</p> - <p>Format <tt>SR</tt> (25 ASCII printing characters)</p> - <pre>V=vv S=ss T=t P=pdop E=ee + <p>The status string is encoded as follows:</p> + <p>Format <tt>SR</tt> (25 ASCII printing characters)</p> + <pre>V=vv S=ss T=t P=pdop E=ee vv = satellites visible ss = relative signal strength t = satellites tracked pdop = position dilution of precision (meters) ee = hardware errors</pre> - <p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p> - <h4>Monitor Data</h4> - <p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag3 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag4 0 | 1</tt> - <dd>Enable verbose <tt>clockstats</tt> recording if set. - </dl> - <h4>Additional Information</h4> - <p><a href="../refclock.html">Reference Clock Drivers</a></p> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> + <p>A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself.</p> + <h4>Monitor Data</h4> + <p>When enabled by the <tt>flag4</tt> fudge flag, an additional line containing the latitude, longitude, elevation and optional deviation data is written to the <tt>clockstats</tt> file. The deviation data operates with an external pulse-per-second (PPS) input, such as a cesium oscillator or another radio clock. The PPS input should be connected to the B event channel and the radio initialized for deviation data on that channel. The deviation data consists of the mean offset and standard deviation of the external PPS signal relative the GPS signal, both in microseconds over the last 16 seconds.</p> + <h4>Fudge Factors</h4> + <dl> + <dt><tt>time1 <i>time</i></tt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. + <dt><tt>time2 <i>time</i></tt> + <dd>Not used by this driver. + <dt><tt>stratum <i>number</i></tt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + <dt><tt>refid <i>string</i></tt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. + <dt><tt>flag1 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag2 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag3 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag4 0 | 1</tt> + <dd>Enable verbose <tt>clockstats</tt> recording if set. + </dl> + <h4>Additional Information</h4> + <p><a href="../refclock.html">Reference Clock Drivers</a></p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html>
\ No newline at end of file diff --git a/html/drivers/driver18.html b/html/drivers/driver18.html index 6acf5f22ab72..a4dc76924462 100644 --- a/html/drivers/driver18.html +++ b/html/drivers/driver18.html @@ -5,12 +5,12 @@ <head> <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>NIST Modem Time Service</title> + <title>NIST/USNO/PTB Modem Time Services</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> </head> <body> - <h3>Automated Computer Time Service (ACTS)</h3> + <h3>NIST/USNO/PTB Modem Time Services</h3> <hr> <h4>Synopsis</h4> <p>Address: 127.127.18.<i>u</i><br> diff --git a/html/drivers/driver19.html b/html/drivers/driver19.html index 961ca09b960a..e498969f10c9 100644 --- a/html/drivers/driver19.html +++ b/html/drivers/driver19.html @@ -2,58 +2,58 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>Heath WWV/WWVH Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> + <head> + <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> + <title>Heath WWV/WWVH Receiver</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>Heath WWV/WWVH Receiver</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.19.<i>u</i><br> - Reference ID: <tt>WWV</tt><br> - Driver ID: <tt>WWV_HEATH</tt><br> - Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 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> - <h4>Description</h4> - <p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. Its claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p> - <p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p> - <p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p> - <p>The clock message consists of 23 ASCII printing characters in the following format:</p> - <pre>hh:mm:ss.f dd/mm/yr<cr> + <body> + <h3>Heath WWV/WWVH Receiver</h3> + <hr> + <h4>Synopsis</h4> + <p>Address: 127.127.19.<i>u</i><br> + Reference ID: <tt>WWV</tt><br> + Driver ID: <tt>WWV_HEATH</tt><br> + Serial Port: <tt>/dev/heath<i>u</i></tt>; 1200 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> + <h4>Description</h4> + <p>This driver supports the Heath GC-1000 Most Accurate Clock, with RS232C Output Accessory. This is a WWV/WWVH receiver somewhat less robust than other supported receivers. It's claimed accuracy is 100 ms when actually synchronized to the broadcast signal, but this doesn't happen even most of the time, due to propagation conditions, ambient noise sources, etc. When not synchronized, the accuracy is at the whim of the internal clock oscillator, which can wander into the sunset without warning. Since the indicated precision is 100 ms, expect a host synchronized only to this thing to wander to and fro, occasionally being rudely stepped when the offset exceeds the default CLOCK_MAX of 128 ms.</p> + <p>The internal DIPswitches should be set to operate at 1200 baud in MANUAL mode and the current year. The external DIPswitches should be set to GMT and 24-hour format. It is very important that the year be set correctly in the DIPswitches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year.</p> + <p>In MANUAL mode the clock responds to a rising edge of the request to send (RTS) modem control line by sending the timecode. Therefore, it is necessary that the operating system implement the <tt>TIOCMBIC</tt> and <tt>TIOCMBIS</tt> ioctl system calls and <tt>TIOCM_RTS</tt> control bit. Present restrictions require the use of a POSIX-compatible programming interface, although other interfaces may work as well.</p> + <p>The clock message consists of 23 ASCII printing characters in the following format:</p> + <pre>hh:mm:ss.f dd/mm/yr<cr> hh:mm:ss.f = hours, minutes, seconds f = deciseconds ('?' when out of spec) dd/mm/yr = day, month, year</pre> - <p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p> - <p>A fudge time1 value of .07 s appears to center the clock offset residuals.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag3 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag4 0 | 1</tt> - <dd>Not used by this driver - </dl> - Additional Information - <p><a href="../refclock.html">Reference Clock Drivers</a> </p> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> + <p>The alarm condition is indicated by '?', rather than a digit, at A. Note that 0?:??:??.? is displayed before synchronization is first established and hh:mm:ss.? once synchronization is established and then lost again for about a day.</p> + <p>A fudge time1 value of .07 s appears to center the clock offset residuals.</p> + <h4>Fudge Factors</h4> + <dl> + <dt><tt>time1 <i>time</i></tt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. + <dt><tt>time2 <i>time</i></tt> + <dd>Not used by this driver. + <dt><tt>stratum <i>number</i></tt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + <dt><tt>refid <i>string</i></tt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>. + <dt><tt>flag1 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag2 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag3 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag4 0 | 1</tt> + <dd>Not used by this driver + </dl> + Additional Information + <p><a href="../refclock.html">Reference Clock Drivers</a> </p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html>
\ No newline at end of file diff --git a/html/drivers/driver20.html b/html/drivers/driver20.html index 17be32cc42ed..9b871a937f09 100644 --- a/html/drivers/driver20.html +++ b/html/drivers/driver20.html @@ -4,7 +4,6 @@ <head> <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i586) [Netscape]"> <title>Generic NMEA GPS Receiver</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> </head> @@ -16,20 +15,23 @@ <p>Address: 127.127.20.<i>u</i><br> Reference ID: <tt>GPS</tt><br> Driver ID: <tt>GPS_NMEA</tt><br> - Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br> + Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 - 115200 bps, 8-bits, no parity<br> + Serial Port: <tt>/dev/gpspps<i>u</i></tt>; for just the PPS signal (this is tried first for PPS, before <tt>/dev/gps<i>u</i></tt>)<br> Serial Port: <tt>/dev/gps<i>u</i></tt>; symlink to server:port (for nmead) Features: <tt>tty_clk</tt></p> <h4>Description</h4> - <p>This driver supports GPS receivers with the <tt>$GPRMC</tt> NMEA output string by default. Alternately the <tt>$GPGGA</tt> or <tt>$GPGLL </tt>may be selected.</p> - <p>The driver expects the receiver to be set up to transmit a <tt>$GPRMC</tt> message every second.</p> - <p>The accuracy depend on the receiver used. Inexpesive GPS models are available with a claimed PPS signal accuracy of 1 <font face="Symbol">m</font>s or better relative to the broadcast signal. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p> - <p>If the Operating System supports the PPSAPI, RFC-2783, it will be used.<br> </p> + <p>This driver supports GPS receivers with the <tt>$GPRMC, $GPGLL, $GPGGA, $GPZDA, and $GPZDG</tt> NMEA sentences by default. Note that Accord's custom NMEA sentence <tt>$GPZDG</tt> reports using the GPS timescale, while the rest of the sentences report UTC. The difference between the two is a whole number of seconds which increases with each leap second insertion in UTC. To avoid problems mixing UTC and GPS timescales, the driver disables processing of UTC sentences once <tt>$GPZDG</tt> is received.</p> + <p>The driver expects the receiver to be set up to transmit at least one supported sentence every second.</p> + <p>The accuracy depends on the receiver used. Inexpensive GPS models are available with a claimed PPS signal accuracy of 1 <font face="Symbol">m</font>s or better relative to the broadcast signal. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p> + <p>If the Operating System supports PPSAPI (<a href="http://www.ietf.org/rfc/rfc2783.txt">RFC 2783</a>), fudge flag1 1 enables its use.<br> </p> <p>The various GPS sentences that this driver recognises look like this:<br> (others quietly ignored)</p> - <pre><tt>$GPRMC,POS_UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CC<cr><lf> -$GPGLL,LAT,LAT_REF,LONG,LONG_REF,POS_UTC,POS_STAT*CC<cr><lf> -$GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CC<cr><lf> + <pre><tt>$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf> +$GPGLL,LAT,LAT_REF,LONG,LONG_REF,UTC,POS_STAT*CS<cr><lf> +$GPGGA,UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS<cr><lf> +$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS<cr><lf> +$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf> - POS_UTC - UTC of position. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff]) + UTC - Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff]) POS_STAT - Position status. (A = Data valid, V = Data invalid) LAT - Latitude (llll.ll) LAT_REF - Latitude direction. (N = North, S = South) @@ -40,7 +42,7 @@ $GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO DATE - Date (ddmmyy) MAG_VAR - Magnetic variation (degrees) (x.x) MAG_REF - Magnetic variation (E = East, W = West) - FIX_MODE - Position Fix Mode ( 0 = Invalid, >0 = Valid) + FIX_MODE - Position Fix Mode (0 = Invalid, >0 = Valid) SAT_USED - Number Satellites used in solution HDOP - Horizontal Dilution of Precision ALT - Antenna Altitude @@ -49,11 +51,23 @@ $GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO G_UNIT - Geoid units (M/F) D_AGE - Age of last DGPS Fix D_REF - Reference ID of DGPS station - CC - Checksum (optional) + GPSTIME - Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f]) + DD - Day of the month (1-31) + MM - Month of the year (1-12) + YYYY - Year + AA.BB - Denotes the signal strength (should be < 05.00) + V - GPS sync status + '0' => INVALID time, + '1' => accuracy of +/- 20ms, + '2' => accuracy of +/- 100ns + CS - Checksum <cr><lf> - Sentence terminator.</tt></pre> - Alternate GPS sentences (other than <tt>$GPRMC</tt> - the default) may be enabled by setting the relevent bits of 'mode' in the server configuration line<br> * server 127.127.20.x mode X<br> bit 0 - enables RMC ( value = 1)<br> bit 1 - enables GGA ( value = 2)<br> bit 2 - enables GLL ( value = 4)<br> - multiple sentences may be selected<br> - <p>The driver will send a <tt>$PMOTG,RMC,0000*1D<cr><lf></tt> message each time a <tt>$GPRMC</tt> string is needed. This is not needed on most GPS receivers because they automatically send the <tt>$GPRMC</tt> string every second and will only work on GPS receivers that understand the <tt>$PMOTG</tt> string. Others will just ignore it.</p> + +<p>Specific GPS sentences and bitrates may be selected by setting bits of the 'mode' in the server configuration line:<br> + <tt>server 127.127.20.x mode X</tt><br> bit 0 - process <tt>$GPMRC</tt> (value = 1)<br> bit 1 - process <tt>$GPGGA</tt> (value = 2)<br> bit 2 - process <tt>$GPGLL</tt> (value = 4)<br> bit 4 - process <tt>$GPZDA</tt> or <tt>$GPZDG</tt> (value = 8)<br> +<p>The default (mode 0) is to process all supported sentences, which results in the last received each cycle being used. Multiple sentences may be selected by adding their mode bit values. The driver uses 4800 bits per second by default. Faster bitrates can be selected using bits 4, 5, and 6 of the mode field:<br><br> + bits 4/5/6 - select serial bitrate (0 for 4800 - the default, 16 for 9600, 32 for 19200, 48 for 38400, 64 for 57600, 80 for 115200)<br></p> + <p>The driver will send a <tt>$PMOTG,RMC,0000*1D<cr><lf></tt> command each poll interval. This is not needed on most GPS receivers because they automatically send <tt>$GPRMC</tt> every second, but helps a Motorola GPS receiver that is otherwise silent. NMEA devices ignore commands they do not understand.</p> <h4>Setting up the Garmin GPS-25XL</h4> Switch off all output with by sending it the following string. <pre>"$PGRMO,,2<cr><lf>"</pre> @@ -62,25 +76,25 @@ $GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO <p>On some systems the PPS signal isn't switched on by default. It can be switched on by sending the following string.</p> <pre>"$PGRMC,,,,,,,,,,,,2<cr><lf>"</pre> <h4>Monitor Data</h4> - <p>The GPS sentence(s) that is used is written to the clockstats file.</p> + <p>The GPS sentence that is used is written to the clockstats file and available with ntpq -c clockvar.</p> <h4>Fudge Factors</h4> <dl> <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. + <dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0. <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. + <dd>Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default 0.0. <dt><tt>stratum <i>number</i></tt> <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. <dt><tt>refid <i>string</i></tt> <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. + <dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1. <dt><tt>flag2 0 | 1</tt> - <dd>Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear. + <dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1. <dt><tt>flag3 0 | 1</tt> - <dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable. + <dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1. <dt><tt>flag4 0 | 1</tt> - <dd>Not used by this driver. + <dd>Obscures location in timecode: 0 for disable (default), 1 for enable. </dl> <p>Additional Information</p> <p><a href="../refclock.html">Reference Clock Drivers</a></p> @@ -88,4 +102,4 @@ $GPGGA,POS_UTC,LAT,LAT_REF,LONG,LONG_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> </body> -</html>
\ No newline at end of file +</html> diff --git a/html/drivers/driver22.html b/html/drivers/driver22.html index e1ed132b6612..140568f98f26 100644 --- a/html/drivers/driver22.html +++ b/html/drivers/driver22.html @@ -2,33 +2,79 @@ <html> - <head> - <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> - <meta name="generator" content="HTML Tidy, see www.w3.org"> - <title>PPS Clock Discipline</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>PPS Clock Discipline</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.22.<i>u</i><br> - Reference ID: <tt>PPS</tt><br> - Driver ID: <tt>PPS</tt><br> - Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt><br> - Requires: PPSAPI interface</p> - <p>Note: This driver supersedes an older one of the same name. The older driver operated with several somewhat archaic signal interface devices, required intricate configuration and was poorly documented. This driver operates only with the PPSAPI interface proposed as an IETF standard. Note also that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p> - <h4>Description</h4> - <p>This driver furnishes an interface for the pulse-per-second (PPS) signal produced by a cesium clock, radio clock or related devices. It can be used to augment the serial timecode generated by a GPS receiver, for example. It can be used to remove accumulated jitter and re-time a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. The driver includes extensive signal sanity checks and grooming algorithms. A range gate and frequency discriminator reject noise and signals with incorrect frequency. A multiple-stage median filter rejects jitter due to hardware interrupt and operating system latencies. A trimmed-mean algorithm determines the best time samples. With typical workstations and processing loads, the incidental jitter can be reduced to a few microseconds.</p> - <p>While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer, as described in the <a href="../prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page.</p> +<head> +<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> +<meta name="generator" content="HTML Tidy, see www.w3.org"> +<title>PPS Clock Discipline</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> + +<body> + +<h3>PPS Clock Discipline</h3> +<hr> + +<p>Last change: + +<!-- #BeginDate format:En2m -->22-Apr-2009 15:02<!-- #EndDate --> +UTC</p> + +<h4>Synopsis</h4> + +<p>Address: 127.127.22.<i>u</i><br> +Reference ID: <tt>PPS</tt><br> +Driver ID: <tt>PPS</tt><br> +Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt><br> +Requires: PPSAPI signal interface for PPS signal processing.</p> + +<p>Note: This driver supersedes an older one of the same name. The older driver operated with several somewhat archaic signal interface devices, required intricate configuration and was poorly documented. This driver requires the Pulse per Second API (PPSAPI)<sup>1</sup>. Note also that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p> + +<h4>Description</h4> + +<p>This driver furnishes an interface for the pulse-per-second (PPS) signal produced by a cesium clock, radio clock or related devices. It can be used to augment the serial timecode generated by a GPS receiver, for example. It can be used to remove accumulated jitter and re-time a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. The driver includes extensive signal sanity checks and grooming algorithms. A range gate and frequency discriminator reject noise and signals with incorrect frequency. A multiple-stage median filter rejects jitter due to hardware interrupt and operating system latencies. A trimmed-mean algorithm determines the best time samples. With typical workstations and processing loads, the incidental jitter can be reduced to a few microseconds.</p> + +<p>While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer, as described in the <a href="../prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page.</p> <p>The driver requires the PPSAPI interface<sup>1</sup>, which is a proposed IETF standard. The interface consists of the <tt>timepps.h</tt> header file and associated kernel support. Support for this interface is included in current versions of Solaris, FreeBSD and Linux and proprietary versions of Tru64 (Alpha) and SunOS. See the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.</p> <p>The PPS source can be connected via a serial or parallel port, depending on the hardware and operating system. A serial port can be dedicated to the PPS source or shared with another device; however, if dedicated the data leads should not be connected, as noise or unexpected signals can cause <tt>ntpd</tt> to exit.</p> - <p>A radio clock is usually connected via a serial port and the PPS source connected via a level converter to the data carrier detect (DCD) pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems where a parallel port and driver are available, the PPS signal can be connected directly to the ACK pin (pin 10) of the connector. Whether the PPS signal is connected via a dedicated port or shared with another device, the driver opens the device <tt>/dev/pps%d</tt>, where <tt>%d</tt> is the unit number. As with other drivers, links can be used to redirect the logical name to the actual physical device.</p> - <p>The driver normally operates like any other driver and uses the same mitigation algorithms and PLL/FLL clock discipline incorporated in the daemon. If kernel PLL/FLL support is available, the kernel PLL/FLL clock discipline can be used instead. The default behavior is not to use the kernel PPS clock discipline, even if present. This driver incorporates a good deal of signal processing to reduce jitter using the median filter and trimmed average algorithms in the driver interface. As the result, performance with minpoll and maxpoll configured at the minimum 4 (16s) is generally better than the kernel PPS discipline. However, fudge flag 3 can be used to enable the kernel PPS discipline if necessary.</p> - <p>Note that the PPS source is considered valid only if the auxiliary source is the prefer peer, is reachable and is selectable to discipline the system clock. By default the stratum assigned to the PPS source is automatically determined. If the auxiliary source is unreachable or inoperative, the stratum is set to 16. Otherwise it is set to the stratum specified by the <tt>fudge stratum</tt> command, if present, or the auxiliary source stratum if not present. Please note the temptation to masquerade as a primary server by forcing the stratum to zero is decidedly dangerous, as it invites timing loops.</p> - <p>The <tt>mode</tt> keyword of the <tt>server</tt> command can be used to set the PPSAPI mode bits which determine the capture edge and echo options. See the <tt>/usr/include/sys/timepps.h</tt> header file for the bit definitions, which must be converted to their decimal equivalents. This overrides the fudge <tt>flag2</tt> option.</p> - <h4>Fudge Factors</h4> + <p>A radio clock is usually connected via a serial port and the PPS source + connected via a level converter to the data carrier detect (DCD) + pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems + where a parallel port and driver are available, the PPS signal can + be connected directly to the ACK pin (DB25 pin 10) of the connector. + Whether the PPS signal is connected via a dedicated port or shared with another + device, the driver opens the device <tt>/dev/pps%d</tt>, + where <tt>%d</tt> is the unit number. As with other drivers, links can be + used to redirect the logical name to the actual physical device.</p> + <p>The driver normally operates like any other driver and uses the same mitigation + algorithms and PLL/FLL clock discipline incorporated in the daemon. + If kernel PLL/FLL support is available, the kernel PLL/FLL clock + discipline can be used instead. The default behavior is not to use + the kernel PPS clock discipline, even if present. This driver incorporates + a good deal of signal processing to reduce jitter using the median + filter algorithm in the driver. As the result, performance + with <tt>minpoll</tt> configured at 4 (16s) is generally + better than the kernel PPS discipline. However, fudge flag 3 can + be used to enable the kernel PPS discipline if necessary.</p> + <p>This driver + is enabled only under one of two conditions (a) a prefer peer other than + this driver is among the survivors of the mitigation algorithms or (b) + there are no survivors and the <tt>minsane</tt> option + of the <tt>tos</tt> command is 0. The prefer peer designates another source + that can reliably number the seconds when available . However, if no + sources are available, the system clock continues to be disciplined by + the PPS driver on an indefinite basis.</p> + <p>A scenario where the latter behavior can be most useful is a planetary orbiter + fleet, for instance in the vicinity of Mars, where contact between orbiters + and Earth only one or two times per Sol (Mars day). These orbiters have a + precise timing reference based on an Ultra Stable Oscillator (USO) with accuracy + in the order of a Cesium oscillator. A PPS signal is derived from the USO + and can be disciplined from Earth on rare occasion or from another orbiter + via NTP. In the above scenario the PPS signal disciplines the spacecraft clock + between NTP updates.</p> + <p>In a similar scenario a PPS signal can be used to discipline the clock between + updates produced by the modem driver. This would provide precise synchronization + without needing the Internet at all.</p> + <h4>Fudge Factors</h4> <dl> <dt><tt>time1 <i>time</i></tt> <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. @@ -41,11 +87,14 @@ <dt><tt>flag1 0 | 1</tt> <dd>Not used by this driver. <dt><tt>flag2 0 | 1</tt> - <dd>Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear. + <dd>Specifies PPS capture on the rising (assert) pulse edge if 0; falling + (clear) edge if 1. (default), + 1 for clear. <dt><tt>flag3 0 | 1</tt> <dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable. <dt><tt>flag4 0 | 1</tt> - <dd>Not used by this driver. + <dd>Record a timestamp once for each second if 1. Useful for constructing + Allan deviation plots.. </dl> <h4>Additional Information</h4> <p><a href="../refclock.html">Reference Clock Drivers</a></p> diff --git a/html/drivers/driver27.html b/html/drivers/driver27.html index 8c2633c50340..a425a9f681a1 100644 --- a/html/drivers/driver27.html +++ b/html/drivers/driver27.html @@ -46,7 +46,6 @@ <dl> <dt><tt>g</tt> CR <dd>Request for signal quality. Answer only valid during (late part of) resync to MSF signal. The response consists of two characters as follows: - <ol> <dl compact> <dt>bit 7 <dd>parity @@ -79,7 +78,6 @@ <dt>bit 2--0 <dd>reception signal quality in the range 0--5 (very poor to very good); if in the range 0--2 no successful reception is to be expected. The reported value drops to zero when not resyncing, ie when first returned byte is not `3'. </dl> - </ol> <dt><tt>h</tt> CR <dd>Request to resync to signal. Can take up from about 30s to 360s. Drains batteries so should not be used excessively. After this the clock time and date should be correct and the phase within 20ms of time as transmitted from the source signal (remember to allow for propagation time). By default the clock resyncs once per day in the late evening/early morning (presumably to catch transitions to/from daylight saving time quickly). This driver code, by default, resyncs at least once per hour to minimise clock wander. <dt><tt>o</tt> CR diff --git a/html/drivers/driver28.html b/html/drivers/driver28.html index 244de1a33d4e..3458768a48f9 100644 --- a/html/drivers/driver28.html +++ b/html/drivers/driver28.html @@ -16,8 +16,10 @@ <p>Address: 127.127.28.<i>u</i><br> Reference ID: <tt>SHM</tt><br> Driver ID: <tt>SHM</tt></p> + <h4>Description</h4> <p>This driver receives its reference clock info from a shared memory-segment. The shared memory-segment is created with owner-only access for unit 0 and 1, and world access for unit 2 and 3</p> + <h4>Structure of shared memory-segment</h4> <pre>struct shmTime { int mode; /* 0 - if valid set @@ -40,15 +42,59 @@ int valid; int dummy[10]; };</pre> + <h4>Operation mode=0</h4> - <p>When the poll-method of the driver is called, the valid-flag of the shared memory-segment is checked:</p> - <p>If set, the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are passed to ntp, and the valid-flag is cleared.</p> - <p>If not set, a timeout is reported to ntp, nothing else happend</p> + <p>Each second, the valid-flag of the shared memory-segment is checked:</p> + <p>If set, the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are passed to ntp, and the valid-flag is cleared and a counter is bumped.</p> + <p>If not set, a counter is bumped</p> <h4>Operation mode=1</h4> - <p>When the poll-method of the driver is called, the valid-flag of the shared memory-segment is checked:</p> - <p>If set, the count-field of the record is remembered, and the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are read. Then, the remembered count is compared to the count now in the record. If both are equal, the values read from the record are passed to ntp. If they differ, another process has modified the record while it was read out (was not able to produce this case), and failure is reported to ntp. The valid flag is cleared.</p> - <p>If not set, a timeout is reported to ntp, nothing else happend</p> - <h4>Fudge Factors</h4> + <p>Each second, the valid-flag of the shared memory-segment is checked:</p> + <p>If set, the count-field of the record is remembered, and the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are read. Then, the remembered count is compared to the count now in the record. If both are equal, the values read from the record are passed to ntp. If they differ, another process has modified the record while it was read out (was not able to produce this case), and failure is reported to ntp. The valid flag is cleared and a counter is bumped.</p> + <p>If not set, a counter is bumped</p> + + +<h4>gpsd</h4> + +<a href="http://gpsd.berlios.de/"><i>gpsd</i></a> +knows how to talk to many GPS devices. +It works with <i>ntpd</i> through the SHM driver. +<P> +The <i>gpsd</i> man page suggests setting minpoll and maxpoll to 4. +That was an attempt to reduce jitter. +The SHM driver was fixed (ntp-4.2.5p138) to collect data each second rather than +once per polling interval so that suggestion is no longer reasonable. +<P> + + +<h4>Clockstats</h4> +If flag4 is set when the driver is polled, a clockstats record is written. +The first 3 fields are the normal date, time, and IP address common to all clockstats records. +<P> +The 4th field is the number of second ticks since the last poll. +The 5th field is the number of good data samples found. The last 64 will be used by ntpd. +The 6th field is the number of sample that didn't have valid data ready. +The 7th field is the number of bad samples. +The 8th field is the number of times the the mode 1 info was update while nptd was trying to grab a sample. +<P> + +Here is a sample showing the GPS reception fading out: +<pre> +54364 84927.157 127.127.28.0 66 65 1 0 0 +54364 84990.161 127.127.28.0 63 63 0 0 0 +54364 85053.160 127.127.28.0 63 63 0 0 0 +54364 85116.159 127.127.28.0 63 62 1 0 0 +54364 85180.158 127.127.28.0 64 63 1 0 0 +54364 85246.161 127.127.28.0 66 66 0 0 0 +54364 85312.157 127.127.28.0 66 50 16 0 0 +54364 85375.160 127.127.28.0 63 41 22 0 0 +54364 85439.155 127.127.28.0 64 64 0 0 0 +54364 85505.158 127.127.28.0 66 36 30 0 0 +54364 85569.157 127.127.28.0 64 0 64 0 0 +54364 85635.157 127.127.28.0 66 0 66 0 0 +54364 85700.160 127.127.28.0 65 0 65 0 0 +</pre> + + <h4>Fudge Factors</h4> <dl> <dt><tt>time1 <i>time</i></tt> <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. @@ -65,7 +111,7 @@ <dt><tt>flag3 0 | 1</tt> <dd>Not used by this driver. <dt><tt>flag4 0 | 1</tt> - <dd>Not used by this driver. + <dd>If flag4 is set, clockstats records will be written when the driver is polled. <h4>Additional Information</h4> <p><a href="../refclock.html">Reference Clock Drivers</a></p> </dl> @@ -73,4 +119,5 @@ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> </body> -</html>
\ No newline at end of file +</html> + diff --git a/html/drivers/driver29.html b/html/drivers/driver29.html index 479978f8f425..dde58ff68446 100644 --- a/html/drivers/driver29.html +++ b/html/drivers/driver29.html @@ -4,15 +4,24 @@ <head> <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> - <title>Trimble Palisade Receiver</title> + <title>Trimble Palisade and Thunderbolt Receivers</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> </head> <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> - <h1><font size="+2">Trimble Palisade Receiver</font> + <h1><font size="+2">Trimble Palisade and Thunderbolt Receivers</font> <hr> </h1> + <table> + <tr> + <td> <h2><img src="../pic/driver29.gif" alt="gif" nosave height="100" width="420"></h2> + </td> + <td> + <h2><img src="../pic/thunderbolt.jpg" alt="jpg" nosave height="270" width="420"></h2> + </td> + </tr> + </table> <h2><font size="+1">Synopsis</font></h2> <table> <tr> @@ -50,12 +59,20 @@ </td> <td><b>9600 baud, 8-bits, 1-stop, odd parity</b></td> </tr> + <tr> + <td> + <div align="right"> + <tt><font size="+1">Serial I/O (Thunderbolt):</font></tt></div> + </td> + <td><b>9600 baud, 8-bits, 1-stop, no parity</b></td> + </tr> </table> <h2><font size="+1">Description</font></h2> The <b>refclock_palisade</b> driver supports <a href="http://www.trimble.com/products/ntp">Trimble Navigation's Palisade Smart Antenna GPS receiver</a>.<br> Additional software and information about the Palisade GPS is available from: <a href="http://www.trimble.com/oem/ntp">http://www.trimble.com/oem/ntp</a>.<br> Latest NTP driver source, executables and documentation is maintained at: <a href="ftp://ftp.trimble.com/pub/ntp">ftp://ftp.trimble.com/pub/ntp</a> <p>This documentation describes version 7.12 of the GPS Firmware and version 2.46 (July 15, 1999) and later, of the driver source.<br> </p> + <p>This documentation describes version 1 of the Thunderbolt Receiver Firmware, no tests have been made on further firmwares, please read "Notes on the Thunderbolt Receiver's Firmware" at the end of this documentation for more information.</p> <h2><font size="+1">Operating System Compatibility</font></h2> The Palisade driver has been tested on the following software and hardware platforms:<br> <center> @@ -97,7 +114,8 @@ <td>20 us</td> </tr> </table> - </center> + </center><P> + <b>Attention</b>: Thunderbolt Receiver has not being tested on the previous software and hardware plataforms. <h2><font size="+1">GPS Receiver</font></h2> The Palisade GPS receiver is an 8-channel smart antenna, housing the GPS receiver, antenna and interface in a single unit, and is designed for rooftop deployment in static timing applications. <p>Palisade generates a PPS synchronized to UTC within +/- 100 ns. The Palisade's external event input with 40 nanosecond resolution is utilized by the Palisade NTP driver for asynchronous precision time transfer.</p> @@ -199,6 +217,19 @@ <tt># and set flag2 to turn off event polling.</tt><br> <tt><a href="#flag2">fudge 127.127.29.0 flag2 1</a></tt><br> <tt>#------------------------------------------------------------------------------</tt><br> </p> + + <h4>Thunderbolt NTP Configuration file</h4> + <tt>#------------------------------------------------------------------------------</tt> + <p>Configuration without event polling:<br> + <tt>#------------------------------------------------------------------------------</tt><br> + <tt># The Primary reference</tt><br> + <tt>server 127.127.29.0 mode 2 # Trimble Thunderbolt GPS (Stratum 1).</tt><br> + <tt># Set packet delay</tt><br> + <tt><a href="#time1">fudge 127.127.29.0 time1 0.020</a></tt><br> + <tt># and set flag2 to turn off event polling.</tt><br> + <tt><a href="#flag2">fudge 127.127.29.0 flag2 1</a></tt><br> + <tt>#------------------------------------------------------------------------------</tt><br> </p> + Currently the Thunderbolt mode doesn't support event polling, the reasons are explained on the "Notes on the Thunderbolt Receiver's Firmware" section at the end of this documentation. <h2><a name="TimeTransfer"></a><font size="+1">Time Transfer and Polling</font></h2> Time transfer to the NTP host is performed via the Palisade's comprehensive time packet output. The time packets are output once per second, and whenever an event timestamp is requested. <p>The driver requests an event time stamp at the end of each polling interval, by pulsing the RTS (request to send) line on the serial port. The Palisade GPS responds with a time stamped event packet.</p> @@ -235,7 +266,7 @@ <h2><font size="+1">Mode Parameter</font></h2> <dl> <dt><tt><font size="+1">mode <i>number</i></font></tt> - <dd>The mode parameter to the server command specifies the specific hardware this driver is for. The default is 0 for a normal Trimble Palisade. The only other option at this time is 1 for a Endrun Praecis in Trimble emulation mode. + <dd>The mode parameter to the server command specifies the specific hardware this driver is for. The default is 0 for a normal Trimble Palisade. The other options are <b>1</b> for an <b>Endrun Praecis</b> in Trimble emulation mode, and <b>2</b> for the <b>Trimble Thunderbolt</b> GPS Disciplined Clock Receiver. </dl> <h2><font size="+1">DEFINEs</font></h2> The following constants are defined in the driver source code. These defines may be modified to improve performance or adapt to new operating systems.<br> @@ -369,6 +400,7 @@ </tr> </table> </center> + <blockquote> <h4>Leap Second Flag Definition:</h4>Bit 0: (1) UTC Time is available<br> Bits 1 - 3: Undefined<br>Bit 4: (1) Leap Scheduled: Leap second pending asserted by GPS control segment.<br>Bit 5: (1) Leap Pending: set 24 hours before, until beginning of leap second.<br>Bit 6: (1) GPS Leap Warning: 6 hours before until 6 hours after leap event<br>Bit 7: (1) Leap In Progress. Only set during the leap second. @@ -576,6 +608,281 @@ </tr> </table> </center> + <h3>Thunderbolt Timing packets Data Format</h3> + Thunderbolt can output 2 synchronous packets. + <h4><b>Primary Timing Packet - 0x8FAB</h4> + <center> + <table> + <tr> + <td><b>Byte</b></td> + <td><b>Bit</b></td> + <td><b>Item</b></td> + <td><b>Type</b></td> + <td><b>Value</b></td> + <td><b>Description</b></td> + </tr> + <tr> + <td>0</td> + <td></td> + <td>Subcode</td> + <td>UINT8</td> + <td></td> + <td>0xAB</td> + </tr> + <tr> + <td>1-4</td> + <td></td> + <td>Time of Week</td> + <td>UINT32</td> + <td></td> + <td>GPS seconds of week</td> + </tr> + <tr> + <td>5-6</td> + <td></td> + <td>Week Number</td> + <td>UINT16</td> + <td></td> + <td>GPS Week Number</td> + </tr> + <tr> + <td>7-8</td> + <td></td> + <td>UTC Offset</td> + <td>SINT16</td> + <td></td> + <td>UTC Offset (seconds)</td> + </tr> + <tr> + <td valign="top">9</td> + <td><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</tr><tr><td>4</tr></table></td> + <td valign="top">Timing Flag</td> + <td valign="top">Bit field</td> + <td valign="top"><table><tr><td>0 or 1</td></tr><tr><td>0 or 1</td></tr><tr><td>0 or 1</td></tr><tr><td>0 or 1</tr><tr><td>0 or 1</tr></table></td></td> + <td valign="top"><table><tr><td>GPS Time or UTC Time</td></tr><tr><td>GPS PPS or UTC PPS</td></tr><tr><td>time is set or time is not set</td></tr><tr><td>have UTC info or no UTC info</td></tr><tr><td>Time from GPS or time from user</td></tr></table></td> + </tr> + <tr> + <td>10</td> + <td></td> + <td>Seconds</td> + <td>UINT8</td> + <td>0-59</td> + <td>(60 for UTC leap second event)</td> + </tr> + <tr> + <td>11</td> + <td></td> + <td>Minutes</td> + <td>UINT8</td> + <td>0-59</td> + <td>Minutes of Hour</td> + </tr> + <tr> + <td>12</td> + <td></td> + <td>Hours</td> + <td>UINT8</td> + <td>0-23</td> + <td>Hour of Day</td> + </tr> + <tr> + <td>13</td> + <td></td> + <td>Day of Month</td> + <td>UINT8</td> + <td>1-31</td> + <td>Day of Month</td> + </tr> + <tr> + <td>14</td> + <td></td> + <td>Month</td> + <td>UINT8</td> + <td>1-12</td> + <td>Month of Year</td> + </tr> + <tr> + <td>15-16</td> + <td></td> + <td>Year</td> + <td>UINT16</td> + <td></td> + <td>Four digits of Year (e.g. 1998)</td> + </tr> + </table> + </center> + <h4><b>Supplemental Timing Packet - 0x8FAC</h4> + <center> + <table> + <tr> + <td><b>Byte</b></td> + <td><b>Bit</b></td> + <td><b>Item</b></td> + <td><b>Type</b></td> + <td><b>Value</b></td> + <td><b>Description</b></td> + </tr> + <tr> + <td>0</td> + <td></td> + <td>Subcode</td> + <td>UINT8</td> + <td></td> + <td>0xAC</td> + </tr> + <tr> + <td valign="top">1</td> + <td></td> + <td valign="top">Receiver Mode</td> + <td valign="top">UINT8</td> + <td valign="top"><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</td></tr><tr><td>4</td></tr><tr><td>5</td></tr><tr><td>6</td></tr></table></td> + <td valign="top"><table><tr><td>Automatic (2D/3D)</td></tr><tr><td>Single Satellite (Time)</td></tr><tr><td>Horizontal (2D)</td></tr><tr><td>Full Position (3D)</td></tr><tr><td>DGPS Reference</td></tr><tr><td>Clock Hold (2D)</td></tr><tr><td>Overdetermined Clock</td></tr></table></td> + </tr> + <tr> + <td valign="top">2</td> + <td></td> + <td valign="top">Disciplining Mode</td> + <td valign="top">UINT8</td> + <td valign="top"><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</td></tr><tr><td>4</td></tr><tr><td>5</td></tr><tr><td>6</td></tr></table></td> + <td valign="top"><table><tr>Normal<td></td></tr><tr><td>Power-Up</td></tr><tr><td>Auto Holdover</td></tr><tr><td>Manual Holdover</td></tr><tr><td>Recovery</td></tr><tr><td>Not Used</td></tr><tr><td>Disciplining disabled</td></tr></table></td> + </tr> + <tr> + <td>3</td> + <td></td> + <td>Self-Survey Progress</td> + <td>UINT 8</td> + <td>0-100%</td> + <td></td> + <tr> + <td>4-7</td> + <td></td> + <td>Holdover Duration</td> + <td>UINT 32</td> + <td></td> + <td>seconds</td> + </tr> + <tr> + <td valign="top">8-9</td> + <td><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</tr><tr><td>4</tr></table></td> + <td valign="top">Critical Alarms</td> + <td valign="top">UINT16</td> + <td valign="top">Bit field</td> + <td valign="top"><table><tr><td>ROM checksum error</td></tr><tr><td>RAM check has failed</td></tr><tr><td>Power supply failure</td></tr><tr><td>FPGA check has failed</td></tr><tr><td>Oscillator control voltage at rail</td></tr></table></td> + </tr> + <tr> + <td valign="top">10-11</td> + <td valign="top"><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</tr><tr><td>4</tr><tr><td>5</td></tr><tr><td>6</td></tr></table></td> + <td valign="top">Minor Alarms</td> + <td valign="top">UINT16</td> + <td valign="top">Bit field</td> + <td valign="top"><table><tr><td>Normal</td></tr><tr><td>Power-Up</td></tr><tr><td>Auto Holdover</td></tr><tr><td>Manual Holdover</tr><tr><td>Recovery</tr><tr><td>Not Used</td></tr><tr><td>Disciplining disabled</td></tr></table></td> + </tr> + <tr> + <td valign="top">12</td> + <td></td> + <td valign="top">GPS Decoding Status</td> + <td valign="top">UINT8</td> + <td valign="top"><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>3</td></tr><tr><td>8</tr><tr><td>9</tr><tr><td>0x0A</td></tr><tr><td>0x0B</td></tr><tr><td>0x0C</td></tr><tr><td>0x10</tr></table></td> + <td valign="top"><table><tr><td>Doing fixes</td></tr><tr><td>Don t have GPS time</td></tr><tr><td>PDOP is too high</td></tr><tr><td>No usable sats</tr><tr><td>Only 1 usable sat</tr><tr><td>Only 2 usable sats</td></tr><tr><td>Only 3 usable sats</td></tr><tr><td>The chosen sat is unusable</td></tr><tr><td>TRAIM rejected the fix</tr></table></td> + </tr> + <tr> + <td valign="top">13</td> + <td></td> + <td valign="top">Disciplining Activity</td> + <td valign="top">UINT8</td> + <td><table><tr><td>0</td></tr><tr><td>1</td></tr><tr><td>2</td></tr><tr><td>3</tr><tr><td>4</tr><tr><td>5</td></tr><tr><td>6</td></tr><tr><td>7</td></tr><tr><td>8</tr></table></td> + <td><table><tr><td>Phase locking</td></tr><tr><td>Oscillator warming up</td></tr><tr><td>Frequency locking</td></tr><tr><td>Placing PPS</tr><tr><td>Initializing loop filter</tr><tr><td>Compensating OCXO</td></tr><tr><td>Inactive</td></tr><tr><td>Not used</td></tr><tr><td>Recovery mode</tr></table></td> + </tr> + <tr> + <td>14</td> + <td></td> + <td>Spare Status 1</td> + <td>UINT8</td> + <td>0</td> + <td></td> + </tr> + <tr> + <td>15</td> + <td></td> + <td>Spare Status 2</td> + <td>UINT8</td> + <td>0</td> + <td></td> + </tr> + <tr> + <td>16-19</td> + <td></td> + <td>PPS Offset</td> + <td>Single</td> + <td></td> + <td>Estimate of UTC/GPS offset (ns)</td> + </tr> + <tr> + <td>20-23</td> + <td></td> + <td>10 MHz Offset</td> + <td>Single</td> + <td></td> + <td>Estimate of UTC/GPS offset (ns)</td> + </tr> + <tr> + <td>24-27</td> + <td></td> + <td>DAC Value</td> + <td>UINT32</td> + <td></td> + <td>Offset binary (0x00 - 0xFFFFF)</td> + </tr> + <tr> + <td>28-31</td> + <td></td> + <td>DAC Voltage</td> + <td>Single</td> + <td></td> + <td>Volts</td> + </tr> + <tr> + <td>32-35</td> + <td></td> + <td>Temperature</td> + <td>Single</td> + <td></td> + <td>degrees C</td> + </tr> + <tr> + <td>36-43</td> + <td></td> + <td>Latitude</td> + <td>Double</td> + <td></td> + <td>radians</td> + </tr> + <tr> + <td>44-51</td> + <td></td> + <td>Longitude</td> + <td>Double</td> + <td></td> + <td>radians</td> + </tr> + <tr> + <td>52-59</td> + <td></td> + <td>Altitude</td> + <td>Double</td> + <td></td> + <td>Meters</td> + </tr> + <tr> + <td>60-67</td> + <td></td> + <td>Spare</td> + <td></td> + <td></td> + <td>For Future Expantion</td> + </tr> + </table> + </center> <h2><a name="Pinouts"></a><font size="+1">Pinouts</font></h2> <a href="#Connection">The following connections are required when connecting Palisade with a host:</a><br> <br> <center> @@ -762,12 +1069,19 @@ </tr> </table> </center> + + <b><h3>Notes on the Thunderbolt Receiver's Firmware</h3></b> + + The support for Thunderbolt Receiver in the palisade driver doesn't support (for now) event-polling, the reason is that the Thunderbolt receiver the patch is written for doesn't support time-on-request, so you just have to sit there and wait for the time to arrive with the PPS. We tried to contact Trimble because there's presumably a firmware update that support it, but we didn't have much luck. +Here is a link explaining the situation:<p> +<a href="https://lists.ntp.isc.org/pipermail/hackers/2006-April/002216.html">https://lists.ntp.isc.org/pipermail/hackers/2006-April/002216.html <p></p> <hr> <p>Questions or Comments:<br> <a href="mailto:sven_dietrich@trimble.com">Sven Dietrich</a><br> <a href="http://www.trimble.com/">Trimble Navigation Ltd.</a></p> - <p>(last updated July 29, 1999)</p> + <a href="mailto:fernandoph@iar.unlp.edu.ar">Fernando P. Hauscarriaga</a><br> + <p>(last updated January 15, 2007)</p> <hr> <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> ; diff --git a/html/drivers/driver34.html b/html/drivers/driver34.html index a98fad89cde2..a742d42a24d3 100644 --- a/html/drivers/driver34.html +++ b/html/drivers/driver34.html @@ -1,117 +1,79 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> + <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> <title>Ultralink Clock</title> - <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> - <link <link href="scripts/style.css" type="text/css" rel="stylesheet"> </HEAD> <BODY> <H3> Ultralink Clock</H3> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> + + <body> + <h3>Ultralink Clock</h3> <hr> <h4>Synopsis</h4> - Address: 127.127.34.<i>u</i><br> - Reference ID: <tt>WWVB</tt><br> - Driver ID: <tt>ULINK</tt><br> - Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 bps, 8-bits, no parity<br> - <br> - Features: <tt>(none)</tt> + <p>Address: 127.127.34.<i>u</i><br> + Reference ID: <tt>WWVB</tt><br> + Driver ID: <tt>ULINK</tt><br> + Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 bps, 8-bits, no parity<br> + Features: <tt>(none)</tt></p> <h4>Description</h4> - <p>This driver supports the Ultralink Model 325 (replacement for Model 320) RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.ulio.com/">http://www.ulio.com/</a>. This driver also supports the Model 320, 330,331,332 decoders in both polled or continous time code mode.<br> - Leap second and quality are supported.</p> - <p>Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.</p> - <hr> - <pre> The Model 325 timecode format is: - - <cr><lf>RQ_1C00LYYYY+DDDUTCS_HH:MM:SSL+5 - - where: - - R = Signal readability indicator, ranging from R1 to R5 - Q R1 is unreadable, R5 is best reception - _ = Space - 1 = prev. received data bit, values: 0, 1 ,M or ? unknown - C = Signal reception from (C)olorado or (H)awaii - 0 = Hours since last WWVB time and flag code update, values - 0 00 to 99 (hopefully always 00) - L = HEX A5 if receiver is locked to WWVB, Space if not - YYYY = Year from 2000 to 2099 - + = '+' if current year is a leap year, else ' ' - DDD = current day in the year from 1 to 365/366 - UTC = timezone (always UTC) - S = Daylight savings indicator, (S)TD, (D)ST, (O) transition - into DST, (I) transition out of DST - _ = Space - HH = UTC hour 0 to 23 - : = Time delimiter, ':' if synced, Space if not - MM = Minutes of current hour from 0 to 59 - : = Time delimiter, ':' if synced, Space if not - SS = Seconds of current minute from 0 to 59 - mm = 10's milliseconds of the current second from 00 to 99 - L = Leap second pending at end of month, (I)nsert, (D)elete - or Space - +5 = UT1 correction, +/- .1 sec increments - </pre> + <p>This driver supports the Ultralink Model 325 (replacement for Model 320) RS-232 powered WWVB receiver. PDF specs available on <a href="http://www.ulio.com/">http://www.ulio.com/</a>. This driver also supports the Model 320, 330,331,332 decoders in both polled or continous time code mode.Leap second and quality are supported. Most of this code is originally from refclock_wwvb.c with thanks. Any mistakes are mine. Any improvements are welcome.</p> + <h4>Model 325 timecode format</h4> + <p><tt><cr><lf>RQ_1C00LYYYY+DDDUTCS_HH:MM:SSL+5</tt></p> + <p>R = Signal readability indicator, ranging from R1 to R5 Q R1 is unreadable, R5 is best reception<br> + _ = Space<br> + 1 = prev. received data bit, values: 0, 1 ,M or ? unknown + C = Signal reception from (C)olorado or (H)awaii 0 = Hours since last WWVB time and flag code update, values 0 00 to 99 (hopefully always 00)<br> + L = HEX A5 if receiver is locked to WWVB, Space if not<br> + YYYY = Year from 2000 to 2099<br> + + = '+' if current year is a leap year, else ' '<br> + DDD = current day in the year from 1 to 365/366<br> + UTC = timezone (always UTC)<br> + S = Daylight savings indicator, (S)TD, (D)ST, (O) transition into DST, (I) transition out of DST<br> + _ = Space<br> + HH = UTC hour 0 to 23<br> + : = Time delimiter, ':' if synced, Space if not<br> + MM = Minutes of current hour from 0 to 59<br> + : = Time delimiter, ':' if synced, Space if not<br> + SS = Seconds of current minute from 0 to 59<br> + mm = 10's milliseconds of the current second from 00 to 99<br> + L = Leap second pending at end of month, (I)nsert, (D)elete or Space<br> + +5 = UT1 correction, +/- .1 sec increments</p> <p>Note that Model 325 reports a very similar output like Model 33X series. The driver for this clock is similar to Model 33X behavior. On a unmodified new ULM325 clock, the polling flag (flag1 =1) needs to be set.</p> - <hr> - <pre> The Model 320 timecode format is: - - <cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr> - - where: - - S = 'S' -- sync'd in last hour, '0'-'9' - hours x 10 since last update, else '?' - Q = Number of correlating time-frames, from 0 to 5 - R = 'R' -- reception in progress, 'N' -- Noisy reception, ' ' -- standby mode - YYYY = year from 1990 to 2089 - DDD = current day from 1 to 366 - + = '+' if current year is a leap year, else ' ' - HH = UTC hour 0 to 23 - MM = Minutes of current hour from 0 to 59 - SS = Seconds of current minute from 0 to 59 - mm = 10's milliseconds of the current second from 00 to 99 - L = Leap second pending at end of month -- 'I' = inset, 'D'=delete - T = DST <-> STD transition indicators - </pre> - <p>Note that this driver does not do anything with the T flag.</p> - <p>The M320 also has a 'U' command which returns UT1 correction information. It is not used in this driver.</p> - <hr> - <pre> The Model 33x timecode format is: - - S9+D 00 YYYY+DDDUTCS HH:MM:SSl+5 - - Where: - - S = sync indicator S insync N not in sync - the sync flag is WWVB decoder sync - nothing to do with time being correct - 9+ = signal level 0 thru 9+ If over 9 indicated as 9+ - D = data bit ( fun to watch but useless ;-) - space - 00 = hours since last GOOD WWVB frame sync - space - YYYY = current year - + = leap year indicator - DDD = day of year - UTC = timezone (always UTC) - S = daylight savings indicator - space - HH = hours - : = This is the REAL in sync indicator (: = insync) - MM = minutes - : = : = in sync ? = NOT in sync - SS = seconds - L = leap second flag - +5 = UT1 correction (sign + digit )) - </pre> - <p>This driver ignores UT1 correction,DST indicator,Leap year and signal level.</p> - <hr> + <h4>Model 320 timecode format</h4> + <p><tt><cr><lf>SQRYYYYDDD+HH:MM:SS.mmLT<cr></tt></p> + <p>S = 'S' -- sync'd in last hour, '0'-'9' - hours x 10 since last update, else '?'<br> + Q = Number of correlating time-frames, from 0 to 5<br> + R = 'R' -- reception in progress,'N' -- Noisy reception, ' ' -- standby mode<br> + YYYY = year from 1990 to 2089<br> + DDD = current day from 1 to 366 + = '+' if current year is a leap year, else ' '<br> + HH = UTC hour 0 to 23<br> + MM = Minutes of current hour from 0 to 59<br> + SS = Seconds of current minute from 0 to 59<br> + mm = 10's milliseconds of the current second from 00 to 99<br> + L = Leap second pending at end of month -- 'I' = insert, 'D'=delete<br> + T = DST <-> STD transition indicators</p> + <p>Note that this driver does not do anything with the T flag. The M320 also has a 'U' command which returns UT1 correction information. It is not used in this driver.</p> + <h4>Model 33x timecode format</h4> + <p><tt>S9+D 00 YYYY+DDDUTCS HH:MM:SSl+5</tt></p> + <p>S = sync indicator S insync N not in sync the sync flag is WWVB decoder sync nothing to do with time being correct </p> + <p>9+ = signal level 0 thru 9+ If over 9 indicated as 9<br> + D = data bit (fun to watch but useless ;-) space<br> + 00 = hours since last GOOD WWVB frame sync space<br> + YYYY = current year + = leap year indicator<br> + DDD = day of year<br> + UTC = timezone (always UTC)<br> + S = daylight savings indicator space<br> + HH = hours : = This is the REAL in sync indicator (: = insync)<br> + MM = minutes : = : = in sync ? = NOT in sync<br> + SS = seconds<br> + L = leap second flag<br> + +5 = UT1 correction (sign + digit ))</p> + <p>This driver ignores UT1 correction, DST indicator,Leap year and signal level.</p> <h4>Fudge factors</h4> <p>flag1 polling enable (1=poll 0=no poll)</p> <hr> - <address><a href="mailto:frank.migge@oracle.com">mail</a></address> - <!-- hhmts start -->Last modified: Mon Mar 8 10:12:08 PST 2004<!-- hhmts end --> - <hr> - <script type="text/javascript" language="javascript" src="Ultralink Clock_files/footer.txt"></script> - </BODY> - </head> - -</html>
\ No newline at end of file + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> +</html> diff --git a/html/drivers/driver36.html b/html/drivers/driver36.html index 72fa665b4aaf..e96f73048cfb 100644 --- a/html/drivers/driver36.html +++ b/html/drivers/driver36.html @@ -18,73 +18,73 @@ Driver ID: <tt>WWV_AUDIO</tt><br> Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br> Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> - <h4>Description</h4> - This driver synchronizes the computer time using data encoded in shortwave radio transmissions from NIST time/frequency stations <a href="http://www.bldrdoc.gov/timefreq/stations/wwv.html">WWV</a> in Ft. Collins, CO, and <a href="http://www.bldrdoc.gov/timefreq/stations/wwvh.htm">WWVH</a> in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10 and 15 MHz from both stations and on 20 MHz from WWV. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically by the driver as propagation conditions change throughout the day and season. The performance of this driver when tracking one of the stations is ordinarily better than 1 ms in time with frequency drift less than 0.1 PPM when not tracking any station.<p>The demodulation and decoding algorithms used by this driver are based on a machine language program developed for the TAPR DSP93 DSP unit, which uses the TI 320C25 DSP chip. The analysis, design and performance of the program running on this unit is described in: Mills, D.L. A precision radio clock for WWV transmissions. Electrical Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. Available from <a href="http://www.eecis.udel.edu/%7emills/reports.html">www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the original program was rebuilt in the C language and adapted to the NTP driver interface. The algorithms have been modified to improve performance, especially under weak signal conditions and to provide an automatic frequency and station selection feature.</p> + <h4>Description</h4>This driver synchronizes the computer time using shortwave radio transmissions from NIST time/frequency stations <a href="http://www.bldrdoc.gov/timefreq/stations/wwv.html">WWV</a> in Ft. Collins, CO, and <a href="http://www.bldrdoc.gov/timefreq/stations/wwvh.htm">WWVH</a> in Kauai, HI. Transmissions are made continuously on 2.5, 5, 10 and 15 MHz from both stations and on 20 MHz from WWV. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically by the driver as propagation conditions change throughout the day and season. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. + <p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 187 PPM (.0187 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p> + <p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 2479 km from the transmitter, the predicted two-hop propagation delay varies from 9.3 ms in sunlight to 9.0 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p> + <p>After calibration relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.1 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p> + <p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p> <p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p> - <p>The WWV signal format is described in NIST Special Publication 432 (Revised 1990). It consists of three elements, a 5-ms, 1000-Hz pulse, which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, which occurs at the beginning of each minute, and a pulse-width modulated 100-Hz subcarrier for the data bits, one bit per second. The WWVH format is identical, except that the 1000-Hz pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for the time of century plus seven bits for the daylight savings time (DST) indicator, leap warning indicator and DUT1 correction.</p> - <h4>Program Architecture</h4> - <p>As in the original program, the clock discipline is modelled as a Markov process, with probabilistic state transitions corresponding to a conventional clock and the probabilities of received decimal digits. The result is a performance level which results in very high accuracy and reliability, even under conditions when the minute beep of the signal, normally its most prominent feature, can barely be detected by ear using a communications receiver.</p> - <p>The analog audio signal from the shortwave radio is sampled at 8000 Hz and converted to digital representation. The 1000/1200-Hz pulses and 100-Hz subcarrier are first separated using two IIR filters, a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The minute synch pulse is extracted using an 800-ms synchronous matched filter and pulse grooming logic which discriminates between WWV and WWVH signals and noise. The second synch pulse is extracted using a 5-ms FIR matched filter and 8000-stage comb filter.</p> - <p>The phase of the 100-Hz subcarrier relative to the second synch pulse is fixed at the transmitter; however, the audio stage in many radios affects the phase response at 100 Hz in unpredictable ways. The driver adjusts for each radio using two 170-ms synchronous matched filters. The I (in-phase) filter is used to demodulate the subcarrier envelope, while the Q (quadrature-phase) filter is used in a tracking loop to discipline the codec sample clock and thus the demodulator phase.</p> - <p>A bipolar data signal is determined from the matched filter I and Q channels using a pulse-width discriminator. The discriminator samples the I channel at 15 ms (<i>n</i>), 200 ms (<i>s</i><sub>1</sub>) and 500 ms (<i>s</i><sub>0</sub>), and the envelope (RMS I and Q channels) at 200 ms (<i>e</i><sub>1</sub>) and the end of the second (<i>e</i><sub>0</sub>). The bipolar data signal is expressed <i>s</i><sub>1</sub> - 2<i>s</i><sub>0 </sub>- <i>n.</i> Note that, since the signals <i>s</i><sub>0</sub> and <i>s</i><sub>1</sub> include the noise <i>n</i>, this term cancels out. The data bit SNR is calculated as 20 log<sub>10</sub>(<i>e</i><sub>1</sub> / <i>e</i><sub>0</sub>). If the driver has not synchronized to the minute pulse, or if the data bit amplitude <i>e</i><sub>1</sub> or SNR are below thresholds, the bit is considered invalid and the bipolar signal is forced to zero.</p> + <h4>Technical Overview</h4> + <p>The driver processes 8-kHz <font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in the broadcast signal. The WWV signal format is described in NIST Special Publication 432 (Revised 1990) and also available on the <a href="http://tf.nist.gov/stations/wwvtimecode.htm">WWV/H web site</a>. It consists of three elements, a 5-ms, 1000-Hz pulse, which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse, which occurs at the beginning of each minute, and a pulse-width modulated 100-Hz subcarrier for the data bits, one bit per second. The WWVH format is identical, except that the 1000-Hz pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for the time of century plus seven bits for the daylight savings time (DST) indicator, leap warning indicator and DUT1 correction.</p> + <p>The demodulation and decoding algorithms used by this driver are based on a machine language program developed for the TAPR DSP93 DSP unit, which uses the TI 320C25 DSP chip. The analysis, design and performance of the program for this unit is described in: Mills, D.L. A precision radio clock for WWV transmissions. Electrical Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp. Available from <a href="http://www.eecis.udel.edu/%7emills/reports.html">www.eecis.udel.edu/~mills/reports.htm</a>. For use in this driver, the original program was rebuilt in the C language and adapted to the NTP driver interface. The algorithms have been modified to improve performance, especially under weak signal conditions and to provide an automatic frequency and station selection feature.</p> + <p>As in the original program, the clock discipline is modelled as a Markov process, with probabilistic state transitions corresponding to a conventional clock and the probabilities of received decimal digits. The result is a performance level with very high accuracy and reliability, even under conditions when the minute beep of the signal, normally its most prominent feature, can barely be detected by ear using a communications receiver.</p> + <h4>Baseband Signal Processing</h4> + <p>The 1000/1200-Hz pulses and 100-Hz subcarrier are first separated using a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The minute pulse is extracted using an 800-ms synchronous matched filter and pulse grooming logic which discriminates between WWV and WWVH signals and noise. The second pulse is extracted using a 5-ms FIR matched filter for each station and a single 8000-stage comb filter.</p> + <p>The phase of the 100-Hz subcarrier relative to the second pulse is fixed at the transmitter; however, the audio stage in many radios affects the phase response at 100 Hz in unpredictable ways. The driver adjusts for each radio using two 170-ms synchronous matched filters. The I (in-phase) filter is used to demodulate the subcarrier envelope, while the Q (quadrature-phase) filter is used in a type-1 phase-lock loop (PLL) to discipline the demodulator phase.</p> + <p>A bipolar data signal is determined from the matched filter subcarrier envelope using a pulse-width discriminator. The discriminator samples the I channel at 15 ms (<i>n</i>), 200 ms (<i>s</i><sub>0</sub>) and 500 ms (<i>s</i><sub>1</sub>), and the envelope (RMS I and Q channels) at 200 ms (<i>e</i><sub>1</sub>) and the end of the second (<i>e</i><sub>0</sub>). The bipolar data signal is expressed 2<i>s</i><sub>1</sub> - <i>s</i><sub>0</sub> - <i>n</i>, where positive values correspond to data 1 and negative values correspond to data 0. Note that, since the signals <i>s</i><sub>0</sub> and <i>s</i><sub>1</sub> include the noise <i>n</i>, the noise component cancels out. The data bit SNR is calculated as 20 log<sub>10</sub>(<i>e</i><sub>1</sub> / <i>e</i><sub>0</sub>). If the driver has not synchronized to the minute pulse, or if the data bit amplitude <i>e</i><sub>1</sub> or SNR are below thresholds, the bit is considered invalid and the bipolar signal is forced to zero.</p> <p>The bipolar signal is exponentially averaged in a set of 60 accumulators, one for each second, to determine the semi-static miscellaneous bits, such as DST indicator, leap second warning and DUT1 correction. In this design a data average value larger than a positive threshold is interpreted as +1 (hit) and a value smaller than a negative threshold as a -1 (miss). Values between the two thresholds, which can occur due to signal fades, are interpreted as an erasure and result in no change of indication.</p> - <p>The BCD digit in each digit position of the timecode is represented as four data bits. The bits are correlated with the bits corresponding to each of the valid decimal digits in this position. If any of the four bits are invalid, the correlated value for all digits in this position is assumed zero. In either case, the values for all digits are exponentially averaged in a likelihood vector associated with this position. The digit associated with the maximum over all averaged values then becomes the maximum likelihood selection for this position and the ratio of the maximum over the next lower value represents the digit SNR.</p> - <p>The decoding matrix contains nine row vectors, one for each digit position. Each row vector includes the maximum likelihood digit, likelihood vector and other related data. The maximum likelihood digit for each of the nine digit positions becomes the maximum likelihood time of the century. A built-in transition function implements a conventional clock with decimal digits that count the minutes, hours, days and years, as corrected for leap seconds and leap years. The counting operation also rotates the likelihood vector corresponding to each digit as it advances. Thus, once the clock is set, each clock digit should correspond to the maximum likelihood digit as transmitted.</p> - <p>Each row of the decoding matrix also includes a compare counter and the most recently determined maximum likelihood digit. If a digit likelihood exceeds the decision level and compares with previous digits for a number of successive minutes in any row, the maximum likelihood digit replaces the clock digit in that row. When this condition is true for all rows and the second epoch has been reliably determined, the clock is set (or verified if it has already been set) and delivers correct time to the integral second. The fraction within the second is derived from the logical master clock, which runs at 8000 Hz and drives all system timing functions.</p> - <p>The logical master clock is derived from the audio codec clock. Its frequency is disciplined by a frequency-lock loop (FLL) which operates independently of the data recovery functions. At averaging intervals determined by the measured jitter, the frequency error is calculated as the difference between the most recent and the current second epoch divided by the interval. The sample clock frequency is then corrected by this amount. When first started, the frequency averaging interval is eight seconds, in order to compensate for intrinsic codec clock frequency offsets up to 125 PPM. Under most conditions, the averaging interval doubles in stages from the initial value to over 1000 seconds, which results in an ultimate frequency precision of 0.125 PPM, or about 11 ms/day.</p> - <p>It is important that the logical clock frequency is stable and accurately determined, since in most applications the shortwave radio will be tuned to a fixed frequency where WWV or WWVH signals are not available throughout the day. In addition, in some parts of the US, especially on the west coast, signals from either or both WWV and WWVH may be available at different times or even at the same time. Since the propagation times from either station are almost always different, each station must be reliably identified before attempting to set the clock.</p> - <p>Reliable station identification requires accurate discrimination between very weak signals in noise and noise alone. The driver very aggresively soaks up every scrap of signal information, but has to be careful to avoid making pseudo-sense of noise alone. The signal quality metric depends on the minute pulse amplitude and SNR measured in second 0 of the minute, together with the data subcarrier amplitude and SNR measured in second 1. If all four values are above defined thresholds a hit is declared, otherwise a miss. The number of hits declared in the last six minutes by each station represents the high order bits of the metric value, while the current minute pulse amplitude repressents the low order bits. The resulting value is then scaled from zero to 100 for use as a quality indicator. It is used by the autotune function described below and reported in the timecode string.</p> + <h4>Maximum-Likelihood Decoder</h4> + <p>The BCD digit in each digit position of the timecode is represented as four data bits. The bits are correlated with the bits corresponding to each of the valid decimal digits in this position. If any of the four bits are invalid, the correlated value for all digits in this position is assumed zero. In either case, the values for all digits are exponentially averaged in a likelihood vector associated with this position. The digit associated with the maximum over all averaged values then becomes the maximum-likelihood candidate for this position and the ratio of the maximum over the next lower value represents the digit SNR.</p> + <p>The decoding matrix contains nine row vectors, one for each digit position. Each row vector includes the maximum-likelihood digit, likelihood vector and other related data. The maximum-likelihood digit for each of the nine digit positions becomes the maximum-likelihood time of the century. A built-in transition function implements a conventional clock with decimal digits that count the minutes, hours, days and years, as corrected for leap seconds and leap years. The counting operation also rotates the likelihood vector corresponding to each digit as it advances. Thus, once the clock is set, each clock digit should correspond to the maximum-likelihood digit as transmitted.</p> + <p>Each row of the decoding matrix also includes a compare counter and the most recently determined maximum-likelihood digit. If a digit likelihood exceeds the decision level and compares with previous digits for a number of successive minutes in any row, the maximum-likelihood digit replaces the clock digit in that row. When this condition is true for all rows and the second epoch has been reliably determined, the clock is set (or verified if it has already been set) and delivers correct time to the integral second. The fraction within the second is derived from the logical master clock, which runs at 8000 Hz and drives all system timing functions.</p> + <h4>Master Clock Discipline</h4> + <p>The logical master clock is derived from the audio codec clock. Its frequency is disciplined by a frequency-lock loop (FLL) which operates independently of the data recovery functions. The maximum value of the 5-ms pulse after the comb filter represents the on-time epoch of the second. At averaging intervals determined by the measured jitter, the frequency error is calculated as the difference between the epoches over the interval divided by the interval itself. The sample clock frequency is then corrected by this amount divided by a time constant of 8.</p> + <p>When first started, the frequency averaging interval is 8 seconds, in order to compensate for intrinsic codec clock frequency offsets up to 125 PPM. Under most conditions, the averaging interval doubles in stages from the initial value to 1024 s, which results in an ultimate frequency resolution of 0.125 PPM, or about 11 ms/day.</p> + <p>The data demodulation functions operate using the subcarrier clock, which is independent of the epoch. However, the data decoding functions are driven by the epoch. The decoder is phase-locked to the epoch in such a way that, when the clock state machine has reliably decoded the broadcast time to the second, the epoch timestamp of that second becomes a candidate to set the system clock.</p> + <p>The comb filter can have a long memory and is vulnerable to noise and stale data, especially when coming up after a long fade. Therefore, a candidate is considered valid only if the 5-ms signal amplitude and SNR are above thresholds. In addition, the system clock is not set until after one complete averaging interval has passed with valid candidates.</p> + <h4>Station Identification</h4> + <p>It is important that the logical clock frequency is stable and accurately determined, since in many applications the shortwave radio will be tuned to a fixed frequency where WWV or WWVH signals are not available throughout the day. In addition, in some parts of the US, especially on the west coast, signals from either or both WWV and WWVH may be available at different times or even at the same time. Since the propagation times from either station are almost always different, each station must be reliably identified before attempting to set the clock.</p> + <p>Reliable station identification requires accurate discrimination between very weak signals in noise and noise alone. The driver very aggressively soaks up every scrap of signal information, but has to be careful to avoid making pseudo-sense of noise alone. The signal quality metric depends on the minute pulse amplitude and SNR measured in second 0 of the minute, together with the data subcarrier amplitude and SNR measured in second 1. If all four values are above defined thresholds a hit is declared, otherwise a miss. 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>The number of hits declared in the last 6 minutes for each station represents the high order bits of the metric, while the current minute pulse amplitude represents the low order bits. Only if the metric is above a defined threshold is the station signal considered acceptable. The metric is also used by the autotune function described below and reported in the timecode string.</p> <h4>Performance</h4> - <p>It is the intent of the design that the accuracy and stability of the indicated time be limited only by the characteristics of the ionospheric propagation medium. Conventional wisdom is that synchronization via the HF medium is good only to a millisecond under the best propagation conditions. The performance of the NTP daemon disciplined by the driver is clearly better than this, even under marginal conditions. Ordinarily, with marginal to good signals and a frequency averaging interval of 1024 s, the frequency is stabilized within 0.1 PPM and the time within 0.5 ms. The frequency stability characteristic is highly important, since the clock may have to free-run for several hours before reacquiring the WWV/H signal.</p> - <p>The expected accuracy over a typical day was determined using the DSP93 and an oscilloscope and cesium oscillator calibrated with a GPS receiver. With marginal signals and allowing 15 minutes for initial synchronization and frequency compensation, the time accuracy determined from the WWV/H second synch pulse was reliably within 125 <font face="Symbol">m</font>s. In the particular DSP93 used for program development, the uncorrected CPU clock frequency offset was 45.8±0.1 PPM. Over the first hour after initial synchronization, the clock frequency drifted about 1 PPM as the frequency averaging interval increased to the maximum 1024 s. Once reaching the maximum, the frequency wandered over the day up to 1 PPM, but it is not clear whether this is due to the stability of the DSP93 clock oscillator or the changing height of the ionosphere. Once the frequency had stabilized and after loss of the WWV/H signal, the frequency drift was less than 0.5 PPM, which is equivalent to 1.8 ms/h or 43 ms/d. This resulted in a step phase correction up to several milliseconds when the signal returned.</p> - <p>The measured propagation delay from the WWV transmitter at Boulder, CO, to the receiver at Newark, DE, is 23.5±0.1 ms. This is measured to the peak of the pulse after the second synch comb filter and includes components due to the ionospheric propagation delay, nominally 8.9 ms, communications receiver delay and program delay. The propagation delay can be expected to change about 0.2 ms over the day, as the result of changing ionosphere height. The DSP93 program delay was measured at 5.5 ms, most of which is due to the 400-Hz bandpass filter and 5-ms matched filter. Similar delays can be expected of this driver.</p> - <h4>Program Operation</h4>The driver begins operation immediately upon startup. It first searches for one or both of the stations WWV and WWVH and attempts to acquire minute synch. This may take some fits and starts, as the driver expects to see several consecutive minutes with good signals and low jitter. If the autotune function is active, the driver will rotate over all five frequencies and both WWV and WWVH stations until at least three good minutes are found.<p>When a minute synch candidate has been found, the driver acquires second synch, which can take up to several minutes, depending on signal quality. At the same time the driver accumulates likelihood values for the unit (seconds) digit of the nine digits of the timecode, plus the seven miscellaneous bits included in the WWV/H transmission format. When a good unit digit has been found, the driver accumlates likelihood values for the remaining eight digits of the timecode. When three repetitions of all nine digits have decoded correctly, which normally takes 15 minutes with good signals, and up to 40 minutes when buried in noise, and the second synch has been acquired, the clock is set (or verified) and is selectable to discipline the system clock.</p> - <p>Once the clock is set, it continues to provide correct timecodes, even if all signals are losst. The time is considered correct as long as the second synch amplitude and SNR are above specified thresholds and jitter is below threshold. As long as the clock is set or verified, the system clock offsets are provided once each minute to the reference clock interface, where they are processed using the same algorithms used with other local reference clocks and remote servers. Using these algorithms, the system clock can in principle be disciplined to a much finer resolution than the 125-<font face="Symbol">m</font>s sample interval would suggest, although the ultimate accuracy is probably limited by propagation delay variations as the ionspheric height varies throughout the day and night.</p> - <p>The codec clock frequency is disciplined during times when WWV/H signals are available. The algorithm refines the frequency offset using increasingly longer averaging intervals to 1024 s, where the precision is about 0.1 PPM. With good signals, it takes well over two hours to reach this degree of precision; however, it can take many more hours than this in case of marginal signals. Once reaching the limit, the algorithm will follow frequency variations due to temperature fluctuations and ionospheric height variations.</p> + <p>It is the intent of the design that the accuracy and stability of the indicated time be limited only by the characteristics of the ionospheric propagation medium. Conventional wisdom is that manual synchronization via oscilloscope and HF medium is good only to a millisecond under the best propagation conditions. The performance of the NTP daemon disciplined by this driver is clearly better than this, even under marginal conditions.</p> + <p>The figure below shows the measured offsets over a typical day near the bottom of the sunspot cycle ending in October, 2006. Variations up to ±0.4 ms can be expected due to changing ionospheric layer height and ray geometry over the day and night.</p> + <div align="center"> + <img src="../pic/offset1211.gif" alt="gif"></div> + <p>The figure was constructed using a 2.4-GHz P4 running FreeBSD 6.1. For these measurements the computer clock was disciplined within a few microseconds of UTC using a PPS signal and GPS receiver and the measured offsets determined from the filegen peerstats data.</p> + <p>The predicted propagation delay from the WWV transmitter at Boulder, CO, to the receiver at Newark, DE, varies over 9.0-9.3 ms. In addition, the receiver contributes 4.7 ms and the 600-Hz bandpass filter 0.9 ms. With these values, the mean error is less than 0.1 ms and varies ±0.3 ms over the day as the result of changing ionospheric height and ray geometry.</p> + <h4>Program Operation</h4> + The driver begins operation immediately upon startup. It first searches for one or both of the stations WWV and WWVH and attempts to acquire minute synch. This may take some fits and starts, as the driver expects to see several consecutive minutes with good signals and low jitter. If the autotune function is active, the driver will rotate over all five frequencies and both WWV and WWVH stations until finding a station and frequency with acceptable metric. + <p>While this is going on the the driver acquires second synch, which can take up to several minutes, depending on signal quality. When minute synch has been acquired, the driver accumulates likelihood values for the unit (seconds) digit of the nine timecode digits, plus the seven miscellaneous bits included in the WWV/H transmission format. When a good unit digit has been found, the driver accumulated likelihood values for the remaining eight digits of the timecode. When three repetitions of all nine digits have decoded correctly, which normally takes 15 minutes with good signals, and up to 40 minutes when buried in noise, and the second synch has been acquired, the clock is set (or verified) and is selectable to discipline the system clock.</p> + <p>Once the clock is set, it continues to provide correct timecodes as long as the signal metric is above threshold, as described in the previous section. As long as the clock is correctly set or verified, the system clock offsets are provided once each minute to the reference clock interface, where they are processed using the same algorithms as with other reference clocks and remote servers.</p> <p>It may happen as the hours progress around the clock that WWV and WWVH signals may appear alone, together or not at all. When the driver has mitigated which station and frequency is best, it sets the reference identifier to the string WV<i>f</i> for WWV and WH<i>f</i> for WWVH, where <i>f</i> is the frequency in megahertz. If the propagation delays have been properly set with the <tt>fudge time1</tt> (WWV) and <tt>fudge time2</tt> (WWVH) commands in the configuration file, handover from one station to the other is seamless.</p> - <p>Once the clock has been set for the first time, it will appear reachable and selectable to discipline the system clock. Operation continues as long as the signal quality from at least one station on at least one frequency is acceptable. A consequence of this design is that, once the clock is set, the time and frequency are disciplined only by the second synch pulse and the clock digits themselves are driven by the clock state machine. If for some reason the state machine drifts to the wrong second, it would never reresynchronize. To protect against this most unlikely situation, if after two days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p> - <p>However, as long as the clock has once been set correctly and allowed to converge to the intrinsic codec clock frequency, it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root dispersion increases at 5 <font face="Symbol">m</font>s per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the dispersion due all causes exceeds 1 s, it is no longer suitable for synchronization.</p> - <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> + <p>Operation continues as long as the signal metric from at least one station on at least one frequency is acceptable. A consequence of this design is that, once the clock is set, the time and frequency are disciplined only by the second synch pulse and the clock digits themselves are driven by the clock state machine. If for some reason the state machine drifts to the wrong second, it would never resynchronize. To protect against this most unlikely situation, if after two days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p> + <p>Once the system clock been set correctly it will continue to read correctly even during the holdover interval, but with increasing dispersion. Assuming the system clock frequency can be disciplined within 1 PPM, it can coast without signals for several days without exceeding the NTP step threshold of 128 ms. During such periods the root distance increases at 15 <font face="Symbol">m</font>s per second, which makes the driver appear less likely for selection as time goes on. Eventually, when the distance due all causes exceeds 1 s, it is no longer suitable for synchronization. Ordinarily, this happens after about 18 hours with no signals. The <tt>tinker maxdist</tt> configuration command can be used to change this value.</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 synch 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 synch, 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 minute synch pulse amplitude and SNR in second 0 and data pulse amplitude and SNR in second 1 to update the signal metric. In principle, the data pulse in second 58 is usable, but the AGC in most radios is not fast enough for a reliable measurement. 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>At the end of each probe, the frequency and station with the maximum metric is chosen, with ties going first to the highest frequency and then to WWV in order. A station is considered valid only if the metric is above a specified threshold' if below, the rotating probes continue until a valid station is found.</p> - <dl> - </dl> - <h4>Diagnostics</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 standard serial port using a level converter such as the CT-17. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</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 synch 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 is inoperative, the driver quietly gives up with no harm done.</p> + <p>Once acquiring minute synch, 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 signal metric as described above. 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>The mitigation procedure selects the frequency and station with the highest valid metric, ties going first to the highest frequency and then to WWV in order. A station is considered valid only if the metric is above a specified threshold; if no station is above the metric, the rotating probes continue until a valid station is found.</p> + <p>The behavior of the autotune function over a typical day is shown in the figure below.</p> + <div align="center"> + <img src="../pic/freq1211.gif" alt="gif"></div> + <p>As expected, the lower frequencies prevail when the ray path is in moonlight (0100-1300 UTC) and the higher frequencies when the path is in sunlight (1300-0100 UTC). Note three periods in the figure show zero frequency when signals are below the minimum for all frequencies and stations.</p> + <h4>Debugging Aids</h4> + <p>The most convenient way to track the driver status is using the <tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays the last determined timecode and related status and error counters, even when the driver is not disciplining the system clock. If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line) is enabled, the driver produces detailed status messages as it operates. If the <tt>fudge flag 4</tt> is set, these messages are written to the <tt>clockstats</tt> file. All messages produced by this driver have the prefix <tt>wwv</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p> <p>The autotune process produces diagnostic information along with the timecode. This is very useful for evaluating the performance of the algorithms, as well as radio propagation conditions in general. The message is produced once each minute for each frequency in turn after minute synch has been acquired.</p> <p><tt>wwv5 status agc epoch secamp/secsnr datamp/datsnr wwv wwvh</tt></p> - <p>where the fields after the <tt>wwv5</tt> identifier are: <tt>status</tt> contains status bits, <tt>agc</tt> audio gain, <tt>epoch </tt>second epoch, <tt>secamp/secsnr </tt>second pulse ampliture/SNR, and <tt>wwv</tt> and <tt>wwvh</tt> are two sets of fields, one each for WWV and WWVH. Each of the two fields has the format</p> + <p>where the fields after the <tt>wwv5</tt> identifier are: <tt>status</tt> contains status bits, <tt>agc</tt> audio gain, <tt>epoch </tt>second epoch, <tt>secamp/secsnr </tt>second pulse amplitude/SNR, and <tt>wwv</tt> and <tt>wwvh</tt> are two sets of fields, one each for WWV and WWVH. Each of the two fields has the format</p> <p><tt>ident score metric minamp/minsnr</tt></p> - <p>where <tt>ident </tt>encodes the station (<tt>WV</tt> for WWV, <tt>WH</tt> for WWVH) and frequency (2, 5, 10, 15 or 20), <tt>score</tt> 32-bit shift register recording the hits (1) and misses (0) of the last 32 probes (hits and misses enter from the right), <tt>metric</tt> is described above, and <tt>minamp/minsnr</tt> minute pulse ampliture/SNR. An example is:</p> - <p><tt>wwv5 000d 111 5753 3967/20.1 3523/10.2 WV20 bdeff 100 8348/30.0 WH20 0000 1 22/-12.4</tt></p> + <p>where <tt>ident </tt>encodes the station (<tt>WV</tt> for WWV, <tt>WH</tt> for WWVH) and frequency (2, 5, 10, 15 or 20), <tt>score</tt> 32-bit shift register recording the hits (1) and misses (0) of the last 32 probes (hits and misses enter from the right), <tt>metric</tt> is described above, and <tt>minamp/minsnr</tt> is the minute pulse ampliture/SNR. An example is:</p> + <pre><tt>wwv5 000d 111 5753 3967/20.1 3523/10.2 WV20 bdeff 100 8348/30.0 WH20 0000 1 22/-12.4</tt></pre> <p>There are several other messages that can occur; these are documented in the source listing.</p> - <h4>Debugging Aids</h4> - <p>The most convenient way to track the driver status is using the <tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays the last determined timecode and related status and error counters, even when the driver is not disciplining the system clock. If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line)is enabled, the driver produces detailed status messages as it operates. If the <tt>fudge flag 4</tt> is set, these messages are written to the <tt>clockstats</tt> file. All messages produced by this driver have the prefix <tt>wwv</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p> <h4>Monitor Data</h4> + When enabled by the <tt>filegen</tt> facility, every received timecode is written to the <tt>clockstats</tt> file in the following format: - <p><tt>sq yyyy ddd hh:mm:ss ld du lset agc ident metric errs freq avg<br> - s</tt> synch indicator (<tt>?</tt> or space) - <tt>q </tt>quality character (see below) - <tt>yyyy </tt>Gregorian year - <tt>ddd </tt>day of year - <tt>hh </tt>hour of day - <tt>mm </tt>minute of hour - <tt>l </tt>leap second warning <tt>L</tt> - <tt>d </tt>DST state <tt>S, D, I, O</tt><br> - <tt>dut </tt>DUT sign and magnitude - <tt>lset </tt>minutes since last set - <tt>agc </tt>audio gain - <tt>ident </tt>station identifier and frequency - <tt>metric </tt>signal metric (0-100) - <tt>errs </tt>data bit errors in last minute - <tt>freq </tt>codec frequency offset (PPM) - <tt>avg </tt>frequency averaging interval (s) -</p> - The fields beginning with <tt>year</tt> and extending through <tt>dut</tt> are decoded from the received data and are in fixed-length format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the following driver-dependent fields, are in variable-length format. + <p><tt>sq yyyy ddd hh:mm:ss l d du lset agc ident metric errs freq avg<br> + </tt></p> + The fields beginning with <tt>yyyy</tt> and extending through <tt>du</tt> are decoded from the received data and are in fixed-length format. The remaining fields are in variable-length format. The fields are as follows: <dl> <dt><tt>s</tt> <dd>The synch indicator is initially <tt>?</tt> before the clock is set, but turns to space when all nine digits of the timecode are correctly set and the decoder is synchronized to the station within 125 <font face="Symbol">m</font>s. @@ -96,12 +96,13 @@ <dt><tt>0x4</tt> <dd>Digit error alarm. Less than nine decimal digits were found in the last minute.<dt><tt>0x2</tt> <dd>Error alarm. More than 40 data bit errors were found in the last minute.<dt><tt>0x1</tt> - <dd>Compare alarm. A maximum likelihood digit failed to agree with the current associated clock digit in the last minute.</dl>It is important to note that one or more of the above alarms does not necessarily indicate a clock error, but only that the decoder has detected a condition that may result in an error. However, the local clock update is not suppressed if any alarm bits are set other than a synch alarm.<dt><tt>yyyy ddd hh:mm:ss</tt> - <dd>The timecode format itself is self explanatory. Since the driver latches the on-time epoch directly from the second synch pulse, the seconds fraction is always zero. Although the transmitted timecode includes only the year of century, the Gregorian year is augmented by 2000.<dt><tt>l</tt> - <dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month of June or December. + <dd>Compare alarm. A maximum-likelihood digit failed to agree with the current associated clock digit in the last minute.</dl>It is important to note that one or more of the above alarms does not necessarily indicate a clock error, but only that the decoder has detected a marginal condition.<dt><tt>yyyy ddd hh:mm:ss</tt> + <dd>The timecode format itself is self explanatory. Since the driver latches the on-time epoch directly from the second synch pulse, the seconds fraction is always zero. Although the transmitted timecode includes only the year of century, the Gregorian year is augmented by 2000. + <dt><tt>l</tt> + <dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month. <dt><tt>d</tt> <dd>The DST state is <tt>S</tt> or <tt>D</tt> when standard time or daylight time is in effect, respectively. The state is <tt>I</tt> or <tt>O</tt> when daylight time is about to go into effect or out of effect, respectively. - <dt><tt>dut</tt> + <dt><tt>du</tt> <dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds. <dt><tt>lset</tt> <dd>Before the clock is set, the interval since last set is the number of minutes since the driver was started; after the clock is set, this is number of minutes since the decoder was last synchronized to the station within 125 <font face="Symbol">m</font>s. @@ -112,9 +113,9 @@ <dt><tt>metric</tt> <dd>The signal metric described above from 0 (no signal) to 100 (best). <dt><tt>errs</tt> - <dd>The bit error counter is useful to determine the quality of the data signal received in the most recent minute. It is normal to drop a couple of data bits under good signal conditions and increasing numbers as conditions worsen. While the decoder performs moderately well even with half the bits are in error in any minute, usually by that point the metric drops below threshold and the decoder switches to a different frequency.<dt><tt>freq</tt> + <dd>The bit error counter is useful to determine the quality of the data signal received in the most recent minute. It is normal to drop a couple of data bits even under good signal conditions and increasing numbers as conditions worsen. While the decoder performs moderately well even with half the bits are in error in any minute, usually by that point the metric drops below threshold and the decoder switches to a different frequency.<dt><tt>freq</tt> <dd>The frequency offset is the current estimate of the codec frequency offset to within 0.1 PPM. This may wander a bit over the day due to local temperature fluctuations and propagation conditions. - <dt><tt>avgt</tt> + <dt><tt>avg</tt> <dd>The averaging time is the interval between frequency updates in powers of two to a maximum of 1024 s. Attainment of the maximum indicates the driver is operating at the best possible resolution in time and frequency. </dl> <p>An example timecode is:</p> diff --git a/html/drivers/driver4.html b/html/drivers/driver4.html index bda4a104afce..788bc46efdca 100644 --- a/html/drivers/driver4.html +++ b/html/drivers/driver4.html @@ -2,65 +2,107 @@ <html> - <head> - <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> - <title>Spectracom 8170 and Netclock/2 WWVB Receivers</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Spectracom 8170 and Netclock/2 WWVB Receivers</h3> - <hr> - <h4>Synopsis</h4> - Address: 127.127.4.<i>u</i><br> - Reference ID: <tt>WWVB</tt><br> - Driver ID: <tt>WWVB_SPEC</tt><br> - Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> - Features: <tt>tty_clk</tt> - <h4>Description</h4> - <p>This driver supports all known Spectracom radio and satellite clocks, including the Model 8170 and Netclock/2 WWVB Synchronized Clocks and the Netclock/GPS GPS Master Clock. The claimed accuracy of the WWVB clocks is 100 usec relative to the broadcast signal. These clocks have proven a reliable source of time, except in some parts of the country with high levels of conducted RF interference. WIth the GPS clock the claimed accuracy is 130 ns. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p> - <p>The DIPswitches on these clocks should be set to 24-hour display, AUTO DST off, data format 0 or 2 (see below) and baud rate 9600. If this clock is used as the source for the IRIG Audio Decoder (<tt>refclock_irig.c</tt> in this distribution), set the DIPswitches for AM IRIG output and IRIG format 1 (IRIG B with signature control).</p> - <p>There are two timecode formats used by these clocks. Format 0, which is available with all clocks, and format 2, which is available with all clocks except the original (unmodified) Model 8170.</p> - <p>Format 0 (22 ASCII printing characters):<br> - <cr><lf>i ddd hh:mm:ss TZ=zz<cr><lf></p> - <p>on-time = first <cr><br> - i = synchronization flag (' ' = in synch, '?' = out synch)<br> - hh:mm:ss = hours, minutes, seconds</p> - <p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours.</p> - <p>Format 2 (24 ASCII printing characters):<br> - lt;cr>lf>iqyy ddd hh:mm:ss.fff ld</p> - <p>on-time = <cr><br> - i = synchronization flag (' ' = in synch, '?' = out synch)<br> - q = quality indicator (' ' = locked, 'A'...'D' = unlocked)<br> - yy = year (as broadcast)<br> - ddd = day of year<br> - hh:mm:ss.fff = hours, minutes, seconds, milliseconds</p> - <p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours. The unlock condition is indicated by other than ' ' at <tt>q</tt>.</p> - <p>The <tt>q</tt> is normally ' ' when the time error is less than 1 ms and a character in the set <tt>A...D</tt> when the time error is less than 10, 100, 500 and greater than 500 ms respectively. The <tt>l</tt> is normally ' ', but is set to <tt>L</tt> early in the month of an upcoming UTC leap second and reset to ' ' on the first day of the following month. The <tt>d</tt> is set to <tt>S</tt> for standard time <tt>S</tt>, <tt>I</tt> on the day preceding a switch to daylight time, <tt>D</tt> for daylight time and <tt>O</tt> on the day preceding a switch to standard time. The start bit of the first <cr> is synchronized to the indicated time as returned.</p> - <p>This driver does not need to be told which format is in use - it figures out which one from the length of the message. A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself, which is a known problem with the older radios.</p> - <h4>Monitor Data</h4> - <p>The driver writes each timecode as received to the <tt>clockstats</tt> file. When enabled by the <tt>flag4</tt> fudge flag, a table of quality data maintained internally by the Netclock/2 is retrieved and written to the <tt>clockstats</tt> file when the first timecode message of a new dayis received.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWVB</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag3 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag4 0 | 1</tt> - <dd>Enable verbose <tt>clockstats</tt> recording if set. - </dl> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> +<head> +<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> +<title>Spectracom WWVB/GPS Receivers</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +<style type="text/css"> +<!-- +.style1 {font-family: Symbol} +--> +</style> +</head> +<body> + +<h3>Spectracom WWVB/GPS Receivers</h3> + +<hr> +Last update: + +<!-- #BeginDate format:En2m -->22-Apr-2009 15:00<!-- #EndDate --> +UTC</p> + +<h4>Synopsis</h4> + +<p>Address: 127.127.4.<i>u</i><br> +Reference ID: <tt>WWVB</tt><br> +Driver ID: <tt>WWVB_SPEC</tt><br> +Serial Port: <tt>/dev/wwvb<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> +Features: Optional PPS signal processing, <tt>tty_clk</tt><br> +Requires: Optional PPS signal processing requires the PPSAPI signal interface.</p> + +<h4>Description</h4> + +<p>This driver supports all known Spectracom radio and satellite clocks, including the Model 8170 and Netclock/2 WWVB Synchronized Clocks and the Netclock/GPS GPS Master Clock. The claimed accuracy of the WWVB clocks is 100 <span class="style1">m</span>s relative to the broadcast signal. These clocks have proven a reliable source of time, except in some parts of the country with high levels of conducted RF interference. WIth the GPS clock the claimed accuracy is 130 ns. However, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.</p> + +<p>The DIPswitches on these clocks should be set to 24-hour display, AUTO DST off, data format 0 or 2 (see below) and baud rate 9600. If this clock is used as the source for the IRIG Audio Decoder (<tt>refclock_irig.c</tt> in this distribution), set the DIPswitches for AM IRIG output and IRIG format 1 (IRIG B with signature control).</p> + +<p>There are two timecode formats used by these clocks. Format 0, which is available with all clocks, and format 2, which is available with all clocks except the original (unmodified) Model 8170.</p> + +<p>Format 0 (22 ASCII printing characters):<br> +<cr><lf>i ddd hh:mm:ss TZ=zz<cr><lf></p> + +<p>on-time = first <cr><br> +i = synchronization flag (' ' = in synch, '?' = out synch)<br> +hh:mm:ss = hours, minutes, seconds</p> + +<p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours.</p> + +<p>Format 2 (24 ASCII printing characters):<br> +lt;cr>lf>iqyy ddd hh:mm:ss.fff ld</p> + +<p>on-time = <cr><br> +i = synchronization flag (' ' = in synch, '?' = out synch)<br> +q = quality indicator (' ' = locked, 'A'...'D' = unlocked)<br> +yy = year (as broadcast)<br> +ddd = day of year<br> +hh:mm:ss.fff = hours, minutes, seconds, milliseconds</p> + +<p>The alarm condition is indicated by other than ' ' at <tt>i</tt>, which occurs during initial synchronization and when received signal is lost for about ten hours. The unlock condition is indicated by other than ' ' at <tt>q</tt>.</p> + +<p>The <tt>q</tt> is normally ' ' when the time error is less than 1 ms and a character in the set <tt>A...D</tt> when the time error is less than 10, 100, 500 and greater than 500 ms respectively. The <tt>l</tt> is normally ' ', but is set to <tt>L</tt> early in the month of an upcoming UTC leap second and reset to ' ' on the first day of the following month. The <tt>d</tt> is set to <tt>S</tt> for standard time <tt>S</tt>, <tt>I</tt> on the day preceding a switch to daylight time, <tt>D</tt> for daylight time and <tt>O</tt> on the day preceding a switch to standard time. The start bit of the first <cr> is synchronized to the indicated time as returned.</p> + +<p>This driver does not need to be told which format is in use - it figures out which one from the length of the message. A three-stage median filter is used to reduce jitter and provide a dispersion measure. The driver makes no attempt to correct for the intrinsic jitter of the radio itself, which is a known problem with the older radios.</p> + +<h4<PPS Signal Processing</h4> + +<p>When PPS signal processing is enabled, and when the system clock has been set by this or another driver and the PPS signal offset is within 0.4 s of the system clock offset, the PPS signal replaces the timecode for as long as the PPS signal is active. If for some reason the PPS signal fails for one or more poll intervals, the driver reverts to the timecode. If the timecode fails for one or more poll intervals, the PPS signal is disconnected.</p> + +<h4>Monitor Data</h4> + +<p>The driver writes each timecode as received to the <tt>clockstats</tt> file. When enabled by the <tt>flag4</tt> fudge flag, a table of quality data maintained internally by the Netclock/2 is retrieved and written to the <tt>clockstats</tt> file when the first timecode message of a new day is received.</p> + +<h4>Fudge Factors</h4> + +<dl> +<dt><tt>time1 <i>time</i></tt> +<dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0. + +<dt><tt>time2 <i>time</i></tt> +<dd>Specifies the serial time offset calibration factor, in seconds and fraction, with default 0.0. + +<dt><tt>stratum <i>number</i></tt> +<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + +<dt><tt>refid <i>string</i></tt> +<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWVB</tt>. + +<dt><tt>flag1 0 | 1</tt> +<dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1. + +<dt><tt>flag2 0 | 1</tt> +<dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1. + +<dt><tt>flag3 0 | 1</tt> +<dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1. + +<dt><tt>flag4 0 | 1</tt> +<dd>Enable verbose <tt>clockstats</tt> recording if set. + +</dl> + +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +</body> </html>
\ No newline at end of file diff --git a/html/drivers/driver6.html b/html/drivers/driver6.html index 8a51f16f035f..eb12bdd39f99 100644 --- a/html/drivers/driver6.html +++ b/html/drivers/driver6.html @@ -1,54 +1,37 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> - <html> - <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> <meta name="generator" content="HTML Tidy, see www.w3.org"> <title>IRIG Audio Decoder</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> </head> - <body> <h3>IRIG Audio Decoder</h3> <hr> <h4>Synopsis</h4> - Address: 127.127.6.<i>u</i><br> - Reference ID: <tt>IRIG</tt><br> - Driver ID: <tt>IRIG_AUDIO</tt><br> - Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> - <p>Note: This driver supersedes an older one of the same name, address and ID which required replacing the original kernel audio driver with another which worked only on older Sun SPARC architectures and SunOS operating systems. The new driver requires no modification of the operating system and works on FreeBSD, SunOS and Solaris. While it is generic and likely portable to other systems, it is somewhat slower than the original, since the extensive signal conditioning, filtering and decoding is done in user space, not kernel space.</p> + Address: 127.127.6.<i>u</i><br> + Reference ID: <tt>IRIG</tt><br> + Driver ID: <tt>IRIG_AUDIO</tt><br> + Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> <h4>Description</h4> - <p>This driver supports the Inter-Range Instrumentation Group (IRIG) standard time distribution signal using the audio codec native to some workstations. This signal is generated by several radio clocks, including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom and TrueTime, among others, although it is often an add-on option. The signal is connected via an optional attenuator box and cable to either the microphone or line-in port. The driver receives, demodulates and decodes the IRIG-B and IRIG-E signal formats using internal filters designed to reduce the effects of noise and interference.</p> + <p>This driver synchronizes the computer time using the Inter-Range Instrumentation Group (IRIG) standard time distribution signal. This signal is generated by several radio clocks, including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom, Symmetricom and TrueTime, among others, although it is often an add-on option. The signal is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC.</p> + <p>The driver requires an audio codec or sound card with sampling rate 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. In this implementation, only one audio driver and codec can be supported on a single machine. In order to assure reliable signal capture, the codec frequency error must be less than 250 PPM (.025 percent). If necessary, the <tt>tinker codec</tt> configuration command can be used to bracket the codec frequency to this range.</p> + <p>For proper operation the IRIG signal source should be configured for analog signal levels, not digital TTL levels. In most radios the IRIG signal is driven ±10 V behind 50 Ohms. In such cases the cable should be terminated at the line-in port with a 50-Ohm resistor to avoid overloading the codec. Where feasible, the IRIG signal source should be operated with signature control so that, if the signal is lost or mutilated, the source produces an unmodulated signal, rather than possibly random digits. The driver automatically rejects the data and declares itself unsynchronized in this case. Some devices, in particular Spectracom radio/satellite clocks, provide additional year and status indication; other devices may not.</p> + <p>In general and without calibration, the driver is accurate within 500 <font face="symbol">m</font>s relative to the IRIG time. After calibrating relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is less than 20 <font face="symbol">m</font>s with standard deviation 10 <font face="symbol">m</font>s. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 <font face="symbol">m</font>s. The processor load due to the driver is 0.6 percent on the P4.</p> + <p>However, be acutely aware that the accuracy with Solaris 2.8 and beyond has been seriously degraded to the order of several milliseconds. The Sun kernel driver has a sawtooth modulation with amplitude over 5 ms P-P and period 5.5 s. This distortion is especially prevalent with Sun Blade 1000 and possibly other systems.</p> + <p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p> <p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver7.html">Radio CHU Audio Demodulator/Decoder</a> and the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p> - <p>The IRIG signal format uses an amplitude-modulated carrier with pulse-width modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy, generally within a few tens of microseconds relative to IRIG time, it can also generate a significant load on the processor with older workstations. Generally, the accuracy with IRIG-E is about ten times worse than IRIG-B, but the processor load is ten times less.</p> - <p>The program processes 8000-Hz <font face="symbol">m</font>-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector and automatic threshold corrector. Cycle crossings relative to the corrected slice level determine the width of each pulse and its value - zero, one or position identifier. The data encode 20 BCD digits which determine the second, minute, hour and day of the year and sometimes the year and synchronization condition. The comb filter exponentially averages the corresponding samples of successive baud intervals in order to reliably identify the reference carrier cycle. A type-II phase-lock loop (PLL) performs additional integration and interpolation to accurately determine the zero crossing of that cycle, which determines the reference timestamp. A pulse-width discriminator demodulates the data pulses, which are then encoded as the BCD digits of the timecode. The timecode and reference timestamp are updated once each second with IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for later processing. At poll intervals of 64 s, the saved samples are processed by a trimmed-mean filter and used to update the system clock.</p> - <p>Infinite impulse response (IIR) filters are used with both IRIG-B and IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a 130-Hz lowpass filter for IRIG-E. These are intended for use with noisy signals, such as might be received over a telephone line or radio circuit, or when interfering signals may be present in the audio passband. The driver determines which IRIG format is in use by sampling the amplitude of each filter output and selecting the one with maximum signal. An automatic gain control feature provides protection against overdriven or underdriven input signal amplitudes. It is designed to maintain adequate demodulator signal amplitude while avoiding occasional noise spikes. In order to assure reliable capture, the decompanded input signal amplitude must be greater than 100 units and the codec sample frequency error less than 250 PPM (.025 percent).</p> - <p>The program performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p> - <p>Unlike other drivers, which can have multiple instantiations, this one supports only one. It does not seem likely that more than one audio codec would be useful in a single machine. More than one would probably chew up too much CPU time anyway.</p> - <h4>IRIG-B Timecode Format</h4> - <p>The 100 elements of the IRIG timecode are numbered from 0 through 99. Position identifiers occur at elements 0, 9, 19 and every ten thereafter to 99. The control function (CF) elements begin at element 50 (CF 1) and extend to element 78 (CF 27). The straight-binary-seconds (SBS) field, which encodes the seconds of the UTC day, begins at element 80 (CF 28) and extends to element 97 (CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27) is device dependent. This driver presently decodes the CF elements, but does nothing with them.</p> - <p>Where feasible, the IRIG signal source should be operated with signature control so that, if the signal is lost or mutilated, the source produces an unmodulated signal, rather than possibly random digits. The driver will automatically reject the data and declare itself unsynchronized in this case. Some devices, in particular Spectracom radio/satellite clocks, provide additional year and status indication in the format:</p> - <pre> - Element CF Function - ------------------------------------- - 55 6 time sync status - 60-63 10-13 BCD year units - 65-68 15-18 BCD year tens -</pre> - Other devices set these elements to zero. - <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>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>Technical Overview</h4> + <p>The IRIG signal format uses an amplitude-modulated carrier with pulse-width modulated data bits. For IRIG-B, the carrier frequency is 1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100 Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy, generally within a few tens of microseconds relative to IRIG time, it can also generate a significant processor load with older workstations. Generally, the accuracy with IRIG-E is about ten times worse than IRIG-B, but the processor load is somewhat less. Technical details about the IRIG formats can be found in <a href="http://handle.dtic.mil/100.2/ADA346250">IRIG Standard 200-98</a>.</p> + <p>The driver processes 8000-Hz <font face="symbol">m</font>-law companded samples using separate signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector and automatic threshold corrector. An infinite impulse response (IIR) 1000-Hz bandpass filter is used for IRIG-B and an IIR 130-Hz lowpass filter for IRIG-E. These are intended for use with noisy signals, such as might be received over a telephone line or radio circuit, or when interfering signals may be present in the audio passband. The driver determines which IRIG format is in use by sampling the amplitude of each filter output and selecting the one with maximum signal.</p> + <p>Cycle crossings relative to the corrected slice level determine the width of each pulse and its value - zero, one or position identifier (PI). The data encode ten characters (20 BCD digits) which determine the second, minute, hour and day of the year and with some IRIG generators the year and synchronization condition. The comb filter exponentially averages the corresponding samples of successive baud intervals in order to reliably identify the reference carrier cycle.</p> + <p>A type-II phase-lock loop (PLL) performs additional integration and interpolation to accurately determine the zero crossing of that cycle, which determines the reference timestamp. A pulse-width discriminator demodulates the data pulses, which are then encoded as the BCD digits of the timecode. The timecode and reference timestamp are updated once each second with IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved for later processing. At poll intervals of 64 s, the saved samples are processed by a median filter and used to update the system clock.</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> + The timecode format used for debugging and data recording includes data helpful in diagnosing problems with the IRIG signal and codec connections. The driver produces one line for each timecode in the following format: + <p><tt>00 00 98 23 19:26:52 2782 143 0.694 10 0.3 66.5 3094572411.00027</tt></p> + <p>If clockstats is enabled, the most recent line is written to the clockstats file every 64 s. If verbose recording is enabled (fudge flag 4) each line is written as generated.</p> + <p>The first field containes the error flags in hex, where the hex bits are interpreted as below. This is followed by the year of century, day of year and time of day. Note that the time of day is for the previous minute, not the current time. The status indicator and year are not produced by some IRIG devices and appear as zeros. Following these fields are the carrier amplitude (0-3000), codec gain (0-255), modulation index (0-1), time constant (4-10), carrier phase error (0±0.5) and carrier frequency error (PPM). The last field is the on-time timestamp in NTP format.</p> <p>The error flags are defined as follows in hex:</p> <dl> <dt><tt>x01</tt> @@ -65,6 +48,8 @@ <dd>Seconds numbering discrepancy. The decoder second does not match the IRIG second. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. <dt><tt>x40</tt> <dd>Codec error (overrun). The machine is not fast enough to keep up with the codec. + <dt><tt>x80</tt> + <dd>Device status error (Spectracom). </dl> <h4>Fudge Factors</h4> <dl> @@ -88,5 +73,4 @@ <hr> <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> </body> - </html>
\ No newline at end of file diff --git a/html/drivers/driver7.html b/html/drivers/driver7.html index 8e050e7219f6..6f4874117f2c 100644 --- a/html/drivers/driver7.html +++ b/html/drivers/driver7.html @@ -13,76 +13,54 @@ <h3>Radio CHU Audio Demodulator/Decoder</h3> <hr> <h4>Synopsis</h4> - Address: 127.127.7.<i>u</i><br> - Reference ID: <tt>CHU</tt><br> - Driver ID: <tt>CHU</tt><br> - Modem Port: <tt>/dev/chu<i>u</i></tt>; 300 baud, 8-bits, no parity<br> - Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br> - Audio Device: <tt>/dev/chu_audio</tt> and <tt>/dev/audioctl</tt> + Address: 127.127.7.<i>u</i><br> + Reference ID: <tt>CHU</tt><br> + Driver ID: <tt>CHU</tt><br> + Modem Port: <tt>/dev/chu<i>u</i></tt>; 300 baud, 8-bits, no parity<br> + Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no parity<br> + Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt> <h4>Description</h4> - <p>This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. It replaces an earlier one, built by Dennis Ferguson in 1988, which required a special line discipline to preprocessed the signal. The new driver includes more powerful algorithms implemented directly in the driver and requires no preprocessing.</p> - <p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.</p> - <p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone or line input port.</p> + <p>This driver synchronizes the computer time using shortwave radio transmissions + from Canadian time/frequency station <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/shortwave_broadcasts_e.html">CHU</a> in + Ottawa, Ontario. CHU transmissions are made continuously on 3.330, + 7.850 and 14.670 MHz in upper sideband, compatible AM mode. An ordinary + shortwave receiver can be tuned manually to one of these frequencies or, in + the case of ICOM receivers, the receiver can be tuned automatically as propagation + conditions change throughout the day and season.</p> + <p>The driver can be compiled to use either an audio codec or soundcard, or a Bell 103-compatible, 300-b/s modem or modem chip, as described on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page. If compiled for a modem, the driver uses it to receive the radio signal and demodulate the data. If compiled for the audio codec, it requires a sampling rate of 8 kHz and <font face="symbol">m</font>-law companding to demodulate the data. This is the same standard as used by the telephone industry and is supported by most hardware and operating systems, including Solaris, FreeBSD and Linux, among others. The radio is connected via an optional attenuator and cable to either the microphone or line-in port of a workstation or PC. In this implementation, only one audio driver and codec can be supported on a single machine.</p> + <p>In general and without calibration, the driver is accurate within 1 ms relative to the broadcast time when tracking a station. However, variations up to 0.3 ms can be expected due to diurnal variations in ionospheric layer height and ray geometry. In Newark DE, 625 km from the transmitter, the predicted one-hop propagation delay varies from 2.8 ms in sunlight to 2.6 ms in moonlight. When not tracking the station the accuracy depends on the computer clock oscillator stability, ordinarily better than 0.5 PPM.</p> + <p>After calibration relative to the PPS signal from a GPS receiver, the mean offset with a 2.4-GHz P4 running FreeBSD 6.1 is generally within 0.2 ms short-term with 0.4 ms jitter. The long-term mean offset varies up to 0.3 ms due to propagation path geometry variations. The processor load due to the driver is 0.4 percent on the P4.</p> + <p>The driver performs a number of error checks to protect against overdriven or underdriven input signal levels, incorrect signal format or improper hardware configuration. The specific checks are detailed later in this page. Note that additional checks are done elsewhere in the reference clock interface routines.</p> <p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">IRIG Audio Decoder</a> pages. They include automatic gain control (AGC), selectable audio codec port and signal monitoring capabilities. For a discussion of these common features, as well as a guide to hookup, debugging and monitoring, see the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p> - <p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.</p> - <p>The decoding algorithms process the data using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.</p> - <p>A timecode in the format described below is assembled when all bursts have been received in the minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the above requirements are met. The <tt>yyyy</tt> year field in the timecode indicates whether a valid format B burst has been received. Upon startup, this field is initialized at zero; when a valid format B burst is received, it is set to the current Gregorian year. The <tt>q</tt> quality character field in the timecode indicates whether a valid timecode has been determined. If any of the high order three bits of this character are set, the timecode is invalid.</p> - <p>Once the clock has been set for the first time, it will appear reachable and selectable to discipline the system clock, even if the broadcast signal is lost. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even in this case, it is unlikely that the system clock could drift more than a few tens of milliseconds during periods of signal loss. To protect against this most unlikely situation, if after four days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.</p> - <p>The last three fields in the timecode are useful in assessing the quality of the radio channel during the most recent minute bursts were received. The <tt>bcnt</tt> field shows the number of format A bursts in the range 1-8. The <tt>dist</tt> field shows the majority decoder distance, or the minimum number of sample repetitions for each digit of the timecode in the range 0-16. The <tt>tsmp</tt> field shows the number of timestamps determined in the range 0-60. For a valid timecode, <tt>bcnt</tt> must be at least 3, <tt>dist</tt> must be greater than <tt>bcnt</tt> and <tt>tsmp</tt> must be at least 20.</p> - <h4>Program Operation</h4> - <p>The program consists of four major parts: the DSP modem, maximum likelihood UART, burst assembler and majority decoder. The DSP modem demodulates Bell 103 modem answer-frequency signals; that is, frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). This is done using a 4th-order IIR filter and limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and followed by a FIR raised-cosine lowpass filter optimized for the 300-b/s data rate. Alternately, the driver can be compiled to delete the modem and input 300 b/s data directly from an external modem via a serial port.</p> - <p>The maximum likelihood UART is implemented using a set of eight 11-stage shift registers, one for each of eight phases of the 300-b/s bit clock. At each phase a new baseband signal value from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a slice level midway between the maximum and minimum over all stages. For each stage, a signal level above this level is a mark (1) and below is a space (0). A quality metric is calculated for each register with respect to the slice level and the a-priori signal consisting of a mark bit (previous stop bit), space (start) bit, eight arbitrary information bits and the first of the two mark (stop) bits.</p> - <p>The shift registers are processed in round-robin order as each modem value arrives until one of them shows a valid framing pattern consisting of a mark bit, space bit, eight arbitrary data bits and a mark bit. When found, the data bits from the register with the best metric is chosen as the maximum likelihood character and the UART begins to process the next character.</p> - <p>The burst assembler processes characters either from the maximum likelihood UART or directly from the serial port as configured. A burst begins when a character is received and is processed after a timeout interval when no characters are received. If the interval between characters is greater than two characters, but less than the timeout interval, the burst is rejected as a runt and a new burst begun. As each character is received, a timestamp is captured and saved for later processing.</p> - <p>A valid burst consists of ten characters in two replicated five-character blocks. A format B block contains the year and other information in ten hexadecimal digits. A format A block contains the timecode in ten decimal digits, the first of which is a framing code (6). The burst assembler must deal with cases where the first character of a format A burst is lost or is noise. This is done using the framing code to correct the phase, either one character early or one character late.</p> - <p>The burst distance is incremented by one for each bit in the first block that matches the corresponding bit in the second block and decremented by one otherwise. In a format B burst the second block is bit-inverted relative to the first, so a perfect burst of five 8-bit characters has distance -40. In a format A block the two blocks are identical, so a perfect burst has distance +40. Format B bursts must be perfect to be acceptable; however, format A bursts, which are further processed by the majority decoder, are acceptable if the distance is at least 28.</p> - <p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 31 through 39. The majority decoder uses a decoding matrix of ten rows, one for each digit position in the timecode, and 16 columns, one for each 4-bit code combination that might be decoded at that position. In order to use the character timestamps, it is necessary to reliably determine the second number of each burst. In a valid burst, the last digit of the two timecodes in the block must match and the value must be in the range 2-9 and greater than in the previous burst.</p> - <p>As each hex digit of a valid burst is processed, the value at the row corresponding to the digit position in the timecode and column corresponding to the code found at that position is incremented. At the end of each minute of transmission, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position of the timecode. However, the first digit (framing code) is always 6, the ninth (second tens) is always 3 and the last (second units) changes for each burst, so are not used.</p> - <p>The maximum over all occurrences at each timecode digit position is the distance for that position and the corresponding code is the maximum likelihood candidate. If the distance is zero, the decoder assumes a miss; if the distance is not more than half the total number of occurrences, the decoder assumes a soft error; if two different codes with the same distance are found, the decoder assumes a hard error. In all these cases the decoder encodes a non-decimal character which will later cause a format error when the timecode is reformatted. The decoding distance is defined as the minimum distance over the first nine digits; the tenth digit varies over the seconds and is uncounted.</p> - <p>The result of the majority decoder is a nine-digit timecode representing the maximum likelihood candidate for the transmitted timecode in that minute. Note that the second and fraction within the minute are always zero and that the actual reference point to calculate timestamp offsets is backdated to the first second of the minute. At this point the timecode block is reformatted and the year, days, hours and minutes extracted along with other information from the format B burst, including DST state, DUT1 correction and leap warning. The reformatting operation checks the timecode for invalid code combinations that might have been left by the majority decoder and rejects the entire timecode if found.</p> - <p>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamp offsets accumulated over the minute. A perfect set of nine bursts could generate as many as 90 timestamps, but the maximum the interface can handle is 60. These are processed by the interface using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.</p> + <h4>Technical Overview</h4> + <p>The driver processes 8-kHz <font face="symbol">m</font>-law companded codec samples using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. The single format B burst is considered correct only if every character matches its repetition in the burst. For the eight format A bursts, a majority decoder requires more than half of the 16 repetitions for each digit decode to the same value. Every character in every burst provides an independent timestamp upon arrival with a potential total of 60 timestamps for each minute.</p> + <p>The CHU timecode format is described on the <a href="http://inms-ienm.nrc-cnrc.gc.ca/time_services/chu_e.html">CHU website</a>. A timecode is assembled when all bursts have been received in each minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the majority decoder declares success. Once the driver has synchronized for the first time, it will appear reachable and selectable to discipline the system clock. It is normal on occasion to miss a minute or two due to signal fades or noise. If eight successive minutes are missed, the driver is considered unreachable and the system clock will free-wheel at the latest determined frequency offset. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even with long intervals between updates, it is unlikely that the system clock will drift more than a few milliseconds during periods of signal loss.</p> + <h4>Baseband Signal Processing</h4> + <p>The program consists of four major parts: the DSP modem, maximum-likelihood UART, burst assembler and majority decoder. The DSP modem demodulates Bell 103 modem answer-frequency signals; that is, frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). It consists of a 500-Hz bandpass filter centered on 2125 Hz followed by a limiter/discriminator and raised-cosine lowpass filter optimized for the 300-b/s data rate. </p> + <p>The maximum likelihood UART is implemented using a set of eight 11-stage shift registers, one for each of eight phases of the 300-b/s bit clock. At each phase a new baseband signal from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a span (difference) and slice level (average) over all 11 stages. For each stage, a signal level above the slice is a mark (1) and below that is a space (0). A quality metric is calculated for each register with respect to the slice level and the a-priori signal consisting of a start bit (space), eight arbitrary information bits and two stop bits (mark).</p> + <p>The shift registers are processed in round-robin order as the phases of each bit arrive. At the end of each bit all eight phases are searched for valid framing bits, sufficient span and best metric. The best candidate found in this way represents the maximum-likelihood character. The process then continues for all ten characters in the burst.</p> + <p>The burst assembler processes characters either from the maximum-likelihood UART or directly from the serial port as configured. A burst begins when a character is received and is processed after a timeout interval when no characters are received. If the interval between characters is greater than two characters, but less than the timeout interval, the burst is rejected as a runt and a new burst begun. As each character is received, a timestamp is captured and saved for later processing.</p> + <p>A valid burst consists of ten characters in two replicated five-character blocks, each block representing ten 4-bit BCD digits. The format B blocks sent in second 31 contain the year and other information in ten digits. The eight format A blocks sent in seconds 32-39 contain the timecode in ten digits, the first of which is a framing code (6). The burst assembler must deal with cases where the first character of a format A burst is lost or is noise. This is done using the framing codes to correct the discrepancy, either one character early or one character late.</p> + <p>The burst distance is incremented by one for each bit in the first block that matches the corresponding bit in the second block and decremented by one otherwise. In a format B burst the second block is bit-inverted relative to the first, so a perfect burst of five 8-bit characters has distance -40. In a format A burst the two blocks are identical, so a perfect burst has distance +40. Format B bursts must be perfect to be acceptable; however, format A bursts, which are further processed by the majority decoder, are acceptable if the distance is at least 28.</p> + <h4>Majority Decoder</h4> + <p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 32 through 39. The majority decoder uses a decoding matrix of ten rows, one for each digit position in the timecode, and 16 columns, one for each 4-bit code combination that might be decoded at that position. In order to use the character timestamps, it is necessary to reliably determine the second number of each burst. In a valid burst, the last digit of the two timecodes in the burst must match and the value must be in the range 2-9 and greater than in the previous burst.</p> + <p>As each digit of a valid burst is processed, the value at the row corresponding to the digit position in the timecode and column corresponding to the code found at that position is incremented. At the end of the minute, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position.</p> + <p>The maximum over all occurrences at each digit position is the distance for that position and the corresponding code is the maximum-likelihood digit. If the distance is not more than half the total number of occurrences, the decoder assumes a soft error and discards all information collected during the minute. The decoding distance is defined as the sum of the distances over the first nine digits; the tenth digit varies over the seconds and is uncounted.</p> + <p>The result of the majority decoder is a nine-digit timecode representing the maximum-likelihood candidate for the transmitted timecode in that minute. Note that the second and fraction within the minute are always zero and that the actual reference point to calculate timestamp offsets is backdated to the first second of the minute. At this point the timecode block is reformatted and the year, days, hours and minutes extracted along with other information from the format B burst, including DST state, DUT1 correction and leap warning. The reformatting operation checks the timecode for invalid code combinations that might have been left by the majority decoder and rejects the entire timecode if found.</p> + <p>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamps accumulated over the minute. A perfect set of eight bursts could generate as many as 80 timestamps, but the maximum the interface can handle is 60. These are processed using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.</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 standard 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>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz. If after five minutes at this frequency not more than two format A bursts have been received for any minute, the driver will tune to 7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and continue in this cycle. 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>Radio Broadcast Format</h4> - <p>The CHU time broadcast includes an audio signal compatible with the Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of nine, ten-character bursts transmitted at 300 b/s and beginning each second from second 31 to second 39 of the minute. Each character consists of eight data bits plus one start bit and two stop bits to encode two hex digits. The burst data consist of five characters (ten hex digits) followed by a repeat of these characters. In format A, the characters are repeated in the same polarity; in format B, the characters are repeated in the opposite polarity.</p> - <p>Format A bursts are sent at seconds 32 through 39 of the minute in hex digits</p> - <p><tt>6dddhhmmss6dddhhmmss</tt></p> - <p>The first ten digits encode a frame marker (<tt>6</tt>) followed by the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>) and second (<tt>ss</tt>). Since format A bursts are sent during the third decade of seconds the tens digit of <tt>ss</tt> is always 3. The driver uses this to determine correct burst synchronization. These digits are then repeated with the same polarity.</p> - <p>Format B bursts are sent at second 31 of the minute in hex digits</p> - <p><tt>xdyyyyttaaxdyyyyttaa</tt></p> - <p>The first ten digits encode a code (<tt>x</tt> described below) followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year (<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight time indicator (<tt>aa</tt>) peculiar to Canada. These digits are then repeated with inverted polarity.</p> - <p>The <tt>x</tt> is coded</p> - <dl> - <dt><tt>1</tt> - <dd>Sign of DUT (0 = +)/dd> - <dt><tt>2</tt> - <dd>Leap second warning. One second will be added. - <dt><tt>4</tt> - <dd>Leap second warning. One second will be subtracted. This is not likely to happen in our universe. - <dt><tt>8</tt> - <dd>Even parity bit for this nibble. - </dl> - <p>By design, the last stop bit of the last character in the burst coincides with 0.5 second. Since characters have 11 bits and are transmitted at 300 b/s, the last stop bit of the first character coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the UART, character interrupts can vary somewhere between the beginning of bit 9 and end of bit 11. These eccentricities can be corrected along with the radio propagation delay using the <tt>fudge time1</tt> variable.</p> + <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 standard serial port using a level converter such as the CT-17. Further details are on the <a href="../audio.html">Reference Clock Audio Drivers</a> page.</p> + <p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.331 MHz. The 1-kHz offset is useful with a narrowband SSB filter where the passband includes the carrier and modem signals. 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 is inoperative, the driver continues in single-frequency mode.</p> + <p>As long as no bursts are received, the driver cycles over the three frequencies in turn, one minute for each station. When bursts are received from one or more stations, the driver operates in a five-minute cycle. During the first four minutes it tunes to the station with the highest metric. During the last minute it alternates between the other two stations in turn in order to measure the metric.</p> <h4>Debugging Aids</h4> - <p>The most convenient way to track the program status is using the <tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays the last determined timecode and related status and error counters, even when the program is not discipline the system clock. If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line)is enabled, the program produces detailed status messages as it operates. If the <tt>fudge flag 4</tt> is set, these messages are written to the <tt>clockstats</tt> file. All messages produced by this driver have the prefix <tt>chu</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p> - <p>With debugging enabled the driver produces messages in the following formats:</p> - <p>A format <tt>chuA</tt> message is produced for each format A burst received in seconds 32 through 39 of the minute:</p> - <p><tt>chuA n b s code</tt></p> - <p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>s</tt> the synchronization distance (0-40) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed and the last ten digits inverted, so the burst</p> - <p><tt>11 40 1091891300ef6e76ecff</tt></p> - <p>is interpreted as containing 11 characters with burst distance 40. The nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI -UTC 31 seconds.</p> - <p>A format <tt>chuB</tt> message is produced for each format B burst received in second 31 of the minute:</p> - <p><tt>chuB n b f s m code</tt></p> - <p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>f</tt> the field alignment (-1, 0, 1), <tt>s</tt>the synchronization distance (0-16), <tt>m</tt>the burst number (2-9) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed, so the burst</p> - <p><tt>10 38 0 16 9 06851292930685129293</tt></p> - <p>is interpreted as containing 11 characters with burst distance 38, field alignment 0, synchronization distance 16 and burst number 9. The nibble-swapped timecode shows day 58, hour 21, minute 29 and second 39.</p> + <p>The most convenient way to track the program status is using the <tt>ntpq</tt> program and the <tt>clockvar</tt> command. This displays the last determined timecode and related status and error counters, even when the program is not discipline the system clock. If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt> command line) is enabled, the program produces detailed status messages as it operates. If the <tt>fudge flag 4</tt> is set, these messages are written to the <tt>clockstats</tt> file. All messages produced by this driver have the prefix <tt>chu</tt> for convenient filtering with the Unix <tt>grep</tt> command.</p> + <p>With debugging enabled the driver produces messages in the following formats: A single message beginning with <tt>chuB</tt> is produced for each format B burst received in second 31, while eight messages beginning with <tt>chuA</tt> are produced for each format A burst received in seconds 32 through 39 of the minute. The first four fields are</p> + <p><tt>stat sig n b</tt></p> + <p>where <tt>stat</tt> is the status code, <tt>sig</tt> the character span, <tt>n</tt> the number of characters in the burst (9-11) and <tt>b</tt> the burst distance (0-40). Good bursts will have spans of a 800 or more and the other numbers near the top of the range specified. See the source for the interpretation of the remaining data in the burst. Note that each character of the burst is encoded as two digits in nibble-swapped order.</p> <p>If the CI-V interface for ICOM radios is active, a debug level greater than 1 will produce a trace of the CI-V command and response messages. Interpretation of these messages requires knowledge of the CI-V protocol, which is beyond the scope of this document.</p> <h4>Monitor Data</h4> - When enabled by the <tt>filegen</tt> facility, every received timecode is written to the <tt>clockstats</tt> file in the following format: - <pre> - sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp + When enabled by the <tt>filegen</tt> facility, every received timecode is written to the <tt>clockstats</tt> file in the following format:<pre> + sq yyyy ddd hh:mm:ss lw dst du lset agc rfrq bcnt dist tsmp s sync indicator q quality character @@ -91,141 +69,78 @@ hh hour of day mm minute of hour ss second of minute - fff millisecond of second - l leap second warning - d DST state + lw leap second warning + dst DST state dut DUT sign and magnitude in deciseconds lset minutes since last set agc audio gain (0-255) - rfrq radio frequency - bcnt burst count - dist decoding distance + ident CHU identifier code + dist decoder distance tsmp timestamps captured </pre> - The fields beginning with <tt>year</tt> and extending through <tt>dut</tt> are decoded from the received data and are in fixed-length format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the following driver-dependent fields, are in variable-length format. + The fields beginning with <tt>year</tt> and extending through <tt>dut</tt> are decoded from the received data and are in fixed-length format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the following driver-dependent fields, are in variable-length format. <dl> <dt><tt>s</tt> - <dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock is correctly set. + <dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock has been correctly set. <dt><tt>q</tt> <dd>The quality character is a four-bit hexadecimal code showing which alarms have been raised during the most recent minute. Each bit is associated with a specific alarm condition according to the following: <dl> <dt><tt>8</tt> - <dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree. - <dt><tt>4</tt> <dd>Timestamp alarm. Fewer than 20 timestamps have been determined. + <dt><tt>4</tt> + <dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree. <dt><tt>2</tt> - <dd>Format alarm. The majority timecode contains invalid bit combinations. - <dt><tt>1</tt> - <dd>Frame alarm. A framing or format error occurred on at least one burst during the minute. - </dl> - <p>It is important to note that one or more of the above alarms does not necessarily indicate a clock error, but only that the decoder has detected a condition that may in future result in an error.</p> - <dt><tt>yyyy ddd hh:mm:ss.fff</tt> + <dd>Format alarm. One or more bursts contained invalid data or was improperly formatted.<dt><tt>1</tt> + <dd>Frame alarm. One or more bursts was improperly framed or contained too many repetition errors.</dl> + <p>The timestamp and decoder alarms are fatal; the data accumulated during the minute are not used to set the clock. The format and fram alarm are nonfatal; only the data in the burst are discarded.</p> + + + + <dt><tt>yyyy ddd hh:mm:ss</tt> <dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode. - <dt><tt>l</tt> - <dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month of June or December. - <dt><tt>d</tt> - <dd>The DST code for Canada encodes the state for all provinces. + + <dt><tt>lw</tt> + <dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month.<dt><tt>dst</tt> + <dd>The DST code for Canada encodes the state for all provinces. It is encoded as two hex characters. <dt><tt>dut</tt> - <dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds. + <dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds. It is encoded as one digit preceeded by sign. <dt><tt>lset</tt> - <dd>Before the clock is set, the interval since last set is the number of minutes since the program was started; after the clock is set, this is number of minutes since the time was last verified relative to the broadcast signal. - <dt><tt>agc</tt> - <dd>The audio gain shows the current codec gain setting in the range 0 to 255. Ordinarily, the receiver audio gain control or IRIG level control should be set for a value midway in this range. - <dt><tt>rfrq</tt> - <dd>The current radio frequency, if the CI-V interface is active, or 'X' if not. - <dt><tt>bcnt</tt> - <dd>The number of format A bursts received during the most recent minute bursts were received. - <dt><tt>dist</tt> - <dd>The minimum decoding distance determined during the most recent minute bursts were received. - <dt><tt>tsmp</tt> - <dd>The number of timestamps determined during the most recent minute bursts were received. + <dd>Before the clock is set, this is the number of minutes since the program was started; after the clock is set, this is the number of minutes since the time was last verified relative to the broadcast signal.<dt><tt>agc</tt> + <dd>The audio gain shows the current codec gain setting in the range 0 to 255. Ordinarily, the receiver audio gain control should be set for a value midway in this range. + <dt><tt>ident</tt> + <dd>The CHU identifier <tt>CHU </tt>followed by the current radio frequency + code, if the CI-V interface is active, or <tt>CHU</tt> if not. The radio + frequncy is encoded as 0 for 3.330 MHz, 1 for 7.850 MHz and 2 + for 14.670 MHz.<dt><tt>dist</tt> + <dd>The decoding distance determined during the most recent minute bursts were received. The values range from 0 to 160, with the higher values indicating better signals. The decoding algorithms require the distance at least 50; otherwise all data in the minute are discarded.<dt><tt>tsmp</tt> + <dd>The number of timestamps determined during the most recent minute bursts were received. The values range from 0 to 60, with the higher values indicating better signals. The decoding algoriths require at least 20 timestamps in the minute; otherwise all data in the minute are discarded. </dl> - <h4>Modes</h4> - <p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code. A missing or zero argument disables the CI-V interface. Following are the ID select codes for the known radios.</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>IC725</td> - <td>0x28</td> - <td>40</td> - <td>IC781</td> - <td>0x26</td> - <td>38</td> - </tr> - <tr> - <td>IC726</td> - <td>0x30</td> - <td>48</td> - <td>R7000</td> - <td>0x08</td> - <td>8</td> - </tr> - <tr> - <td>IC735</td> - <td>0x04</td> - <td>4</td> - <td>R71</td> - <td>0x1A</td> - <td>26</td> - </tr> - <tr> - <td>IC751</td> - <td>0x1c</td> - <td>28</td> - <td>R7100</td> - <td>0x34</td> - <td>52</td> - </tr> - <tr> - <td>IC761</td> - <td>0x1e</td> - <td>30</td> - <td>R72</td> - <td>0x32</td> - <td>50</td> - </tr> - <tr> - <td>IC765</td> - <td>0x2c</td> - <td>44</td> - <td>R8500</td> - <td>0x4a</td> - <td>74</td> - </tr> - <tr> - <td>IC775</td> - <td>0x46</td> - <td>68</td> - <td>R9000</td> - <td>0x2a</td> - <td>42</td> - </tr> - </table> <h4>Fudge Factors</h4> <dl> <dt><tt>time1 <i>time</i></tt> <dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds and fraction, with default 0.0. + <dt><tt>time2 <i>time</i></tt> <dd>Not used by this driver. + <dt><tt>stratum <i>number</i></tt> <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + <dt><tt>refid <i>string</i></tt> <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>CHU</tt>. + <dt><tt>flag1 0 | 1</tt> <dd>Not used by this driver. + <dt><tt>flag2 0 | 1</tt> <dd>When the audio driver is compiled, this flag selects the audio input port, where 0 is the mike port (default) and 1 is the line-in port. It does not seem useful to select the compact disc player port. + <dt><tt>flag3 0 | 1</tt> <dd>When the audio driver is compiled, this flag enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started. + <dt><tt>flag4 0 | 1</tt> <dd>Enable verbose <tt>clockstats</tt> recording if set. + </dl> <hr> <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> diff --git a/html/drivers/driver8.html b/html/drivers/driver8.html index fc12f3307d43..8e81e5f57f16 100644 --- a/html/drivers/driver8.html +++ b/html/drivers/driver8.html @@ -158,7 +158,28 @@ <p><b><tt>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</tt></b><br> <br></p> + <li><b><tt>server 127.127.8.0-3 mode 20</tt></b> + <p><b><tt>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</tt></b><br> + </p> + <p>Driving the DCF clocks at 75 baud may help to get them to work with a bunch of common USB serial converters, that do 75 but cannot do 50 baud at all, e.g. those based on Prolific PL2303. + <br></p> + + <li><b><tt>server 127.127.8.0-3 mode 21</tt></b> + <p><b><tt>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </tt></b><br> + </p> + <p>See comment from mode 20 clock. + <br></p> + + <li><b><tt>server 127.127.8.0-3 mode 22</tt></b> + <p><b><tt>MEINBERG, mode 2 but with POWERUP trust </tt></b><br> + </p> + + <li><b><tt>server 127.127.8.0-3 mode 23</tt></b> + <p><b><tt>MEINBERG, mode 7 but with POWERUP trust </tt></b><br> + </p> + </ul> + <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> <h4>Operation</h4> <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> diff --git a/html/drivers/driver9.html b/html/drivers/driver9.html index 112f2d7a3f60..812ab13b8136 100644 --- a/html/drivers/driver9.html +++ b/html/drivers/driver9.html @@ -2,57 +2,56 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>Magnavox MX4200 GPS Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> + <head> + <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> + <meta name="GENERATOR" content="Mozilla/4.01 [en] (Win95; I) [Netscape]"> + <title>Magnavox MX4200 GPS Receiver</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>Magnavox MX4200 GPS Receiver</h3> - <hr> - <h4>Synopsis</h4> - Address: 127.127.9.<i>u</i><br> - Reference ID: <tt>GPS</tt><br> - Driver ID: <tt>GPS_MX4200</tt><br> - Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br> - Features: <tt>ppsclock</tt> (required) - <h4>Description</h4> - <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. It requires the <tt>ppsclock</tt> line discipline or streams module described in the <a href="../ldisc.html">Line Disciplines and Streams Modules</a> page. It also requires a level converter such as described in the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page.</p> - <p>This driver supports all compatible receivers such as the 6-channel MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.</p> - <p><a href="http://www.leica-gps.com/"><img src="../pic/9400n.jpg" alt="Leica MX9400N Navigator" height="143" width="180" align="left"></a> <a href="http://www.leica-gps.com/">Leica Geosystems</a> acquired the Magnavox commercial GPS technology business in February of 1994. They now market and support former Magnavox GPS products such as the MX4200 and its successors.</p> - <br clear="LEFT"> - <p>Leica MX9400N Navigator.</p> - <h4>Operating Modes</h4> - <p>This driver supports two modes of operation, static and mobile, controlled by clock flag 2.</p> - <p>In static mode (the default) the driver assumes that the GPS antenna is in a fixed location. The receiver is initially placed in a "Static, 3D Nav" mode, where latitude, longitude, elevation and time are calculated for a fixed station. An average position is calculated from this data. After 24 hours, the receiver is placed into a "Known Position" mode, initialized with the calculated position, and then solves only for time.</p> - <p>In mobile mode, the driver assumes the GPS antenna is mounted on a moving platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic, 3D Nav" mode and solves for position, altitude and time while moving. No position averaging is performed.</p> - <h4>Monitor Data</h4> - <p>The driver writes each timecode as received to the <tt>clockstats</tt> file. Documentation for the <cite>NMEA-0183</cite> proprietary sentences produced by the MX4200 can be found in <a href="../mx4200data.html">MX4200 Receiver Data Format</a>.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Not used by this driver. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Assume GPS receiver is on a mobile platform if set. - <dt><tt>flag3 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag4 0 | 1</tt> - <dd>Not used by this driver. - </dl> - <h4>Additional Information</h4> - <p><a href="../refclock.html">Reference Clock Drivers</a> </p> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> + <body> + <h3>Magnavox MX4200 GPS Receiver</h3> + <hr> + <h4>Synopsis</h4> + Address: 127.127.9.<i>u</i><br> + Reference ID: <tt>GPS</tt><br> + Driver ID: <tt>GPS_MX4200</tt><br> + Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 baud, 8-bits, no parity<br> + Features: <tt>ppsclock</tt> (required) + <h4>Description</h4> + <p>This driver supports the Magnavox MX4200 Navigation Receiver adapted to precision timing applications. This driver supports all compatible receivers such as the 6-channel MX4200, MX4200D, and the 12-channel MX9212, MX9012R, MX9112.</p> + <p><a href="http://www.leica-gps.com/"><img src="../pic/9400n.jpg" alt="Leica MX9400N Navigator" height="143" width="180" align="left"></a> <a href="http://www.leica-gps.com/">Leica Geosystems</a> acquired the Magnavox commercial GPS technology business in February of 1994. They now market and support former Magnavox GPS products such as the MX4200 and its successors.</p> + <br clear="LEFT"> + <p>Leica MX9400N Navigator.</p> + <h4>Operating Modes</h4> + <p>This driver supports two modes of operation, static and mobile, controlled by clock flag 2.</p> + <p>In static mode (the default) the driver assumes that the GPS antenna is in a fixed location. The receiver is initially placed in a "Static, 3D Nav" mode, where latitude, longitude, elevation and time are calculated for a fixed station. An average position is calculated from this data. After 24 hours, the receiver is placed into a "Known Position" mode, initialized with the calculated position, and then solves only for time.</p> + <p>In mobile mode, the driver assumes the GPS antenna is mounted on a moving platform such as a car, ship, or aircraft. The receiver is placed in "Dynamic, 3D Nav" mode and solves for position, altitude and time while moving. No position averaging is performed.</p> + <h4>Monitor Data</h4> + <p>The driver writes each timecode as received to the <tt>clockstats</tt> file. Documentation for the <cite>NMEA-0183</cite> proprietary sentences produced by the MX4200 can be found in <a href="mx4200data.html">MX4200 Receiver Data Format</a>.</p> + <h4>Fudge Factors</h4> + <dl> + <dt><tt>time1 <i>time</i></tt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. + <dt><tt>time2 <i>time</i></tt> + <dd>Not used by this driver. + <dt><tt>stratum <i>number</i></tt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0. + <dt><tt>refid <i>string</i></tt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>. + <dt><tt>flag1 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag2 0 | 1</tt> + <dd>Assume GPS receiver is on a mobile platform if set. + <dt><tt>flag3 0 | 1</tt> + <dd>Not used by this driver. + <dt><tt>flag4 0 | 1</tt> + <dd>Not used by this driver. + </dl> + <h4>Additional Information</h4> + <p><a href="../refclock.html">Reference Clock Drivers</a> </p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html>
\ No newline at end of file diff --git a/html/drivers/mx4200data.html b/html/drivers/mx4200data.html new file mode 100644 index 000000000000..6f9ac30b6646 --- /dev/null +++ b/html/drivers/mx4200data.html @@ -0,0 +1,1074 @@ +<html> + + <head> + <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> + <title>MX4200 Receiver Data Format</title> + <link href="../scripts/style.css" type="text/css" rel="stylesheet"> + </head> + + <body> + <h1>MX4200 Receiver Data Format</h1> + <hr> + <h2>Table of Contents</h2> + <ul> + <li><a href="#control">Control Port Sentences</a> + <li><a href="#input">Control Port Input Sentences</a> + <ul> + <li><a href="#input_000">$PMVXG,000</a> Initialization/Mode Control - Part A + <li><a href="#input_001">$PMVXG,001</a> Initialization/Mode Control - Part B + <li><a href="#input_007">$PMVXG,007</a> Control Port Configuration + <li><a href="#input_023">$PMVXG,023</a> Time Recovery Configuration + <li><a href="#input_gpq">$CDGPQ,YYY</a> Query From a Remote Device / Request to Output a Sentence + </ul> + <li><a href="#output">Control Port Output Sentences</a> + <ul> + <li><a href="#output_000">$PMVXG,000</a> Receiver Status + <li><a href="#output_021">$PMVXG,021</a> Position, Height, Velocity + <li><a href="#output_022">$PMVXG,022</a> DOPs + <li><a href="#output_030">$PMVXG,030</a> Software Configuration + <li><a href="#output_101">$PMVXG,101</a> Control Sentence Accept/Reject + <li><a href="#output_523">$PMVXG,523</a> Time Recovery Configuration + <li><a href="#output_830">$PMVXG,830</a> Time Recovery Results + </ul> + </ul> + <hr> + <h2><a name="control">Control Port Sentences</a></h2> + <p>The Control (CDU) Port is used to initialize, monitor, and control the receiver. The structure of the control port sentences is based on the <cite>NMEA-0183</cite> Standard for Interfacing Marine Electronics Navigation Devices (version 1.5). For more details, please refer to the <cite>NMEA-0183</cite> Specification available from the <a href="http://www.nmea.org/">National Marine Electronics Association</a>.</p> + <p>Reserved characters are used to indicate the beginning and the end of records in the data stream, and to delimit data fields within a sentence. Only printable ASCII characters (Hex 20 through 7F) may be used in a sentence. <a href="#table_2">Table 2</a> lists the reserved characters and defines their usage. <a href="#table_1">Table 1</a> illustrates the general Magnavox proprietary NMEA sentence format.</p> + <h4><a name="table_1">Table 1. Magnavox Proprietary NMEA Sentence Format</a></h4> + <code>$PMVXG,XXX,...................*CK </code> + <p></p> + <table border> + <tr> + <th>Character</th> + <th>Meaning</th> + </tr> + <tr> + <td><code>$</code></td> + <td>Sentence Start Character</td> + </tr> + <tr> + <td><code>P</code></td> + <td>Special ID (P = Proprietary)</td> + </tr> + <tr> + <td><code>MVX</code></td> + <td>Originator ID (MVX = Magnavox)</td> + </tr> + <tr> + <td><code>G</code></td> + <td>Interface ID (G = GPS)</td> + </tr> + <tr> + <td><code>XXX</code></td> + <td>Sentence Type</td> + </tr> + <tr> + <td><code>...</code></td> + <td>Data</td> + </tr> + <tr> + <td><code>*</code></td> + <td>Optional Checksum Field Delimiter</td> + </tr> + <tr> + <td><code>CK</code></td> + <td>Optional Checksum</td> + </tr> + </table> + <h4><a name="table_2">Table 2. NMEA Sentence Reserved Characters</a></h4> + <table border> + <tr> + <th>Character</th> + <th>Hex Value</th> + <th>Usage</th> + </tr> + <tr> + <td><code>$</code></td> + <td>24</td> + <td>Start of Sentence Identifier</td> + </tr> + <tr> + <td><code>{cr}{lf}</code></td> + <td>0D 0A</td> + <td>End of Sentence Identifier</td> + </tr> + <tr> + <td><code>,</code></td> + <td>2C</td> + <td>Sentence Delimiter</td> + </tr> + <tr> + <td><code>*</code></td> + <td>2A</td> + <td>Optional Checksum Field Delimiter</td> + </tr> + </table> + <p>Following the start character <code>$</code>, are five characters which constitute the block label of the sentence. For Magnavox proprietary sentences, this label is always <code>PMVXG</code>. The next field after the block label is the sentence type, consisting of three decimal digits.</p> + <p>The data, delimited by commas, follows the sentence type. Note that the receiver uses a free-format parsing algorithm, so you need not send the exact number of characters shown in the examples. You will need to use the commas to determine how many bytes of data need to be retrieved.</p> + <p>The notation <code>CK</code> shown in <a href="#table_1">Table 1</a> symbolically indicates the optional checksum in the examples. The checksum is computed by exclusive-ORing all of the bytes between the <code>$</code> and the <code>*</code> characters. The <code>$</code>, <code>*</code> and the checksum are not included in the checksum computation.</p> + <p>Checksums are optional for Control Port input sentences, but are highly recommended to limit the effects of communication errors. Magnavox receivers always generate checksums for Control Port output sentences.</p> + <p>ASCII data characters are transmitted in the following format:</p> + <table border> + <tr> + <td>Data Bits</td> + <td>8 (msb always 0)</td> + </tr> + <tr> + <td>Parity</td> + <td>None</td> + </tr> + <tr> + <td>Stop Bits</td> + <td>1</td> + </tr> + </table> + <p>NULL fields are fields which do not contain any data. They would appear as two commas together in the sentence format, except for the final field. Some Magnavox proprietary sentences require that the format contain NULL fields. mandatory NULL fields are identified by an '*' next to the respective field.</p> + <hr> + <h2><a name="input">Control Port Input Sentences</a></h2> + These are the subset of the MX4200 control port input sentences sent by the NTP driver to the GPS receiver. + <hr> + <h3><a name="input_000">$PMVXG,000</a></h3> + <h4>Initialization/Mode Control - Part A</h4> + Initializes the time, position and antenna height of the MX4200. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Default</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Day</td> + <td> </td> + <td>Int</td> + <td> </td> + <td>1-31</td> + </tr> + <tr> + <td>2</td> + <td>Month</td> + <td> </td> + <td>Int</td> + <td> </td> + <td>1-12</td> + </tr> + <tr> + <td>3</td> + <td>Year</td> + <td> </td> + <td>Int</td> + <td> </td> + <td>1991-9999</td> + </tr> + <tr> + <td>4</td> + <td>GMT Time</td> + <td>HHMMSS</td> + <td>Int</td> + <td> </td> + <td>000000-235959</td> + </tr> + <tr> + <td>5</td> + <td>WGS-84 Latitude</td> + <td>DDMM.MMMM</td> + <td>Float</td> + <td>0.0</td> + <td>0 - 8959.9999</td> + </tr> + <tr> + <td>6</td> + <td>North/South Indicator</td> + <td> </td> + <td>Char</td> + <td>N</td> + <td>N,S</td> + </tr> + <tr> + <td>7</td> + <td>WGS-84 Longitude</td> + <td>DDDMM.MMMM</td> + <td>Float</td> + <td>0.0</td> + <td>0 - 17959.9999</td> + </tr> + <tr> + <td>8</td> + <td>East/West Indicator</td> + <td> </td> + <td>Char</td> + <td>E</td> + <td>E,W</td> + </tr> + <tr> + <td>9</td> + <td>Altitude (height above Mean Sea Level) in meters (WGS-84)</td> + <td>Meters</td> + <td>Float</td> + <td>0.0</td> + <td>+/-99999.0</td> + </tr> + <tr> + <td>10</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + </table> + Example:<br> + <code>$PMVXG,000,,,,,,,,,,*48</code><br> + <code>$PMVXG,000,,,,,5128.4651,N,00020.0715,W,58.04,*4F</code> + <hr> + <h3><a name="input_001">$PMVXG,001</a></h3> + <h4>Initialization/Mode Control - Part B</h4> + Specifies various navigation parameters: Altitude aiding, acceleration DOP limits, and satellite elevation limits. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Default</th> + <th>Range</th> + </tr> + <tr> + <td>*1</td> + <td>Constrain Altitude</td> + <td> </td> + <td>Int</td> + <td>1</td> + <td>0=3D Only<br> + 1=Auto<br> + 2=2D Only</td> + </tr> + <tr> + <td>2</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + <tr> + <td>*3</td> + <td>Horizontal Acceleration Factor</td> + <td>m/sec^2</td> + <td>Float</td> + <td>1.0</td> + <td>0.5-10.0</td> + </tr> + <tr> + <td>*4</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + <tr> + <td>*5</td> + <td>VDOP Limit</td> + <td> </td> + <td>Int</td> + <td>10</td> + <td>1-9999</td> + </tr> + <tr> + <td>*6</td> + <td>HDOP Limit</td> + <td> </td> + <td>Int</td> + <td>10</td> + <td>1-9999</td> + </tr> + <tr> + <td>7</td> + <td>Elevation Limit</td> + <td>Deg</td> + <td>Int</td> + <td>5</td> + <td>0-90</td> + </tr> + <tr> + <td>8</td> + <td>Time Output Mode</td> + <td> </td> + <td>Char</td> + <td>U</td> + <td>U=UTC<br> + L=Local Time</td> + </tr> + <tr> + <td>9</td> + <td>Local Time Offset</td> + <td>HHMM</td> + <td>Int</td> + <td>0</td> + <td>+/- 0-2359</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,001,3,,0.1,0.1,10,10,5,U,0*06</code> + <hr> + <h3><a name="input_007">$PMVXG,007</a></h3> + <h4>Control Port Output Configuration</h4> + This message enables or disables output of the specified sentence and defines the output rate. The user sends this message for each sentence that the receiver is to output. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Default</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Control Port Output Block Label</td> + <td> </td> + <td>Char</td> + <td> </td> + <td> </td> + </tr> + <tr> + <td>2</td> + <td>Clear Current Output List</td> + <td> </td> + <td>Int</td> + <td> </td> + <td>0=No<br> + 1=Yes</td> + </tr> + <tr> + <td>3</td> + <td>Add/Delete Sentence from List</td> + <td> </td> + <td>Int</td> + <td> </td> + <td>1=Append<br> + 2=Delete</td> + </tr> + <tr> + <td>4</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + <tr> + <td>5</td> + <td>Sentence Output Rate</td> + <td>Sec</td> + <td>Int</td> + <td> </td> + <td>1-9999</td> + </tr> + <tr> + <td>6</td> + <td># digits of Precision for CGA and GLL sentences</td> + <td> </td> + <td>Int</td> + <td>2</td> + <td>2-4</td> + </tr> + <tr> + <td>7</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + <tr> + <td>8</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + <td> </td> + </tr> + </table> + Example:<br> + <code>$PMVXG,007,022,0,1,,1,,,*4F</code> + <hr> + <h3><a name="input_023">$PMVXG,023</a></h3> + <h4>Time Recovery Configuration</h4> + This message is used to enable/disable the time recovery feature of the receiver. The time synchronization for the 1PPS output is specified in addition to a user time bias and an error tolerance for a valid pulse. This record is accepted in units configured for time recovery. If the back panel contains a 1PPS outlet, the receiver is a time recovery unit. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Default</th> + <th>Range</th> + </tr> + <tr> + <td>*1</td> + <td>Time Recovery Mode</td> + <td> </td> + <td>Char</td> + <td>D</td> + <td>D=Dynamic<br> + S=Static<br> + K=Known Position<br> + N=No Time Recovery</td> + </tr> + <tr> + <td>2</td> + <td>Time Synchronization</td> + <td> </td> + <td>Char</td> + <td>G</td> + <td>U=UTC<br> + G=GPS</td> + </tr> + <tr> + <td>3</td> + <td>Time Mark Mode</td> + <td> </td> + <td>Char</td> + <td>A</td> + <td>A=Always<br> + V=Valid Pulses Only</td> + </tr> + <tr> + <td>4</td> + <td>Maximum Time Error</td> + <td>Nsec</td> + <td>Int</td> + <td>100</td> + <td>50-1000</td> + </tr> + <tr> + <td>5</td> + <td>User Time Bias</td> + <td>Nsec</td> + <td>Int</td> + <td>0</td> + <td>+/- 99999</td> + </tr> + <tr> + <td>6</td> + <td>ASCII Time Message Control</td> + <td> </td> + <td>Int</td> + <td>0</td> + <td>0=No Output<br> + 1=830 to Control Port<br> + 2=830 to Equipment Port</td> + </tr> + <tr> + <td>7</td> + <td>Known Pos PRN</td> + <td> </td> + <td>Int</td> + <td>0</td> + <td>1-32<br> + 0=Track All Sats</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,023,S,U,A,500,0,1,*16</code> + <hr> + <h3><a name="input_gpq">$CDGPQ,YYY</a></h3> + <h4>Query From a Remote Device / Request to Output a Sentence</h4> + Enables the controller to request a one-time transmission of a specific block label. To output messages at a periodic rate, refer to input sentence <a href="#input_007">$PMVXG,007</a>. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Default</th> + <th>Range</th> + </tr> + <tr> + <td>1:CD</td> + <td>ID of Remote Device</td> + <td> </td> + <td>Char</td> + <td> </td> + <td>(See <cite>NMEA-0183</cite>)</td> + </tr> + <tr> + <td>2:GP</td> + <td>GPS</td> + <td> </td> + <td>Char</td> + <td> </td> + <td>(See <cite>NMEA-0183</cite>)</td> + </tr> + <tr> + <td>3:Q</td> + <td>Query</td> + <td> </td> + <td>Char</td> + <td> </td> + <td>(See <cite>NMEA-0183</cite>)</td> + </tr> + <tr> + <td>4:YYY</td> + <td>Label of Desired Sentence</td> + <td> </td> + <td>Char</td> + <td> </td> + <td>Any Valid NMEA or Magnavox Sentence Type</td> + </tr> + </table> + Example:<br> + <code>$CDGPQ,030*5E</code> + <hr> + <h2><a name="output">Control Port Output Sentences</a></h2> + These are the subset of the MX4200 control port output sentences recognized by the NTP driver. + <hr> + <h3><a name="output_000">$PMVXG,000</a></h3> + <h4>Receiver Status</h4> + Returns the current status of the receiver including the operating mode, number of satellites visible, and the number of satellites being tracked. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Current Receiver Status</td> + <td> </td> + <td>Char</td> + <td>ACQ=Reacquisition<br> + ALT=Constellation Selection<br> + IAC=Initial Acquisition<br> + IDL=Idle, No Satellites<br> + NAV=Navigating<br> + STS=Search The Sky<br> + TRK=Tracking</td> + </tr> + <tr> + <td>2</td> + <td>Number of Satellites that should be Visible</td> + <td> </td> + <td>Int</td> + <td>0-12</td> + </tr> + <tr> + <td>3</td> + <td>Number of Satellites being Tracked</td> + <td> </td> + <td>Int</td> + <td>0-12</td> + </tr> + <tr> + <td>4</td> + <td>Time since Last Navigation</td> + <td>HHMM</td> + <td>Int</td> + <td>0-2359</td> + </tr> + <tr> + <td>5</td> + <td>Initialization Status</td> + <td> </td> + <td>Int</td> + <td>0=Waiting for Initialization<br> + 1=Initialization Complete</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,000,TRK,3,3,0122,1*19</code> + <hr> + <h3><a name="output_021">$PMVXG,021</a></h3> + <h4>Position, Height, Velocity</h4> + This sentence gives the receiver position, height, navigation mode and velocity north/east. <em>This sentence is intended for post analysis applications.</em> + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>UTC Measurement Time</td> + <td>Seconds into the week</td> + <td>Float</td> + <td>0-604800.00</td> + </tr> + <tr> + <td>2</td> + <td>WGS-84 Latitude</td> + <td>DDMM.MMMM</td> + <td>Float</td> + <td>0-89.9999</td> + </tr> + <tr> + <td>3</td> + <td>North/South Indicator</td> + <td> </td> + <td>Char</td> + <td>N, S</td> + </tr> + <tr> + <td>4</td> + <td>WGS-84 Longitude</td> + <td>DDDMM.MMMM</td> + <td>Float</td> + <td>0-179.9999</td> + </tr> + <tr> + <td>5</td> + <td>East/West Indicator</td> + <td> </td> + <td>Char</td> + <td>E, W</td> + </tr> + <tr> + <td>6</td> + <td>Altitude (MSL)</td> + <td>Meters</td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>7</td> + <td>Geoidal Height</td> + <td>Meters</td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>8</td> + <td>Velocity East</td> + <td>M/Sec</td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>9</td> + <td>Velocity North</td> + <td>M/Sec</td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>10</td> + <td>Navigation Mode</td> + <td> </td> + <td>Int</td> + <td><em>Navigating</em><br> + 1=Position From a Remote Device<br> + 2=2D<br> + 3=3D<br> + 4=2D differential<br> + 5=3D differential<br> + <em>Not Navigating</em><br> + 51=Too Few Satellites<br> + 52=DOPs too large<br> + 53=Position STD too large<br> + 54=Velocity STD too large<br> + 55=Too many iterations for velocity<br> + 56=Too many iterations for position<br> + 57=3 Sat Startup failed</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,021,142244.00,5128.4744,N,00020.0593,W,00054.4,0047.4,0000.1,-000.2,03*66</code> + <hr> + <h3><a name="output_022">$PMVXG,022</a></h3> + <h4>DOPs</h4> + This sentence reports the DOP (Dilution Of Precision) values actually used in the measurement processing corresponding to the satellites listed. The satellites are listed in receiver channel order. Fields 11-16 are output only on 12-channel receivers. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>UTC Measurement Time</td> + <td>Seconds into the week</td> + <td>Float</td> + <td>0-604800.00</td> + </tr> + <tr> + <td>2</td> + <td>East DOP (EDOP)</td> + <td> </td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>3</td> + <td>North DOP (NDOP)</td> + <td> </td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>4</td> + <td>Vertical DOP (VDOP)</td> + <td> </td> + <td>Float</td> + <td> </td> + </tr> + <tr> + <td>5</td> + <td>PRN on Channel #1</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>6</td> + <td>PRN on Channel #2</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>7</td> + <td>PRN on Channel #3</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>8</td> + <td>PRN on Channel #4</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>9</td> + <td>PRN on Channel #5</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>10</td> + <td>PRN on Channel #6</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>11</td> + <td>PRN on Channel #7</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>12</td> + <td>PRN on Channel #8</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>13</td> + <td>PRN on Channel #9</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>14</td> + <td>PRN on Channel #10</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>15</td> + <td>PRN on Channel #11</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + <tr> + <td>16</td> + <td>PRN on Channel #12</td> + <td> </td> + <td>Int</td> + <td>1-32</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,022,142243.00,00.7,00.8,01.9,27,26,10,09,13,23*77</code> + <hr> + <h3><a name="output_030">$PMVXG,030</a></h3> + <h4>Software Configuration</h4> + This sentence contains the navigation processor and baseband firmware version numbers. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Nav Processor Version Number</td> + <td> </td> + <td>Char</td> + <td> </td> + </tr> + <tr> + <td>2</td> + <td>Baseband Firmware Version Number</td> + <td> </td> + <td>Char</td> + <td> </td> + </tr> + </table> + Example:<br> + <code>$PMVXG,030,DA35,015</code> + <hr> + <h3><a name="output_101">$PMVXG,101</a></h3> + <h4>Control Sentence Accept/Reject</h4> + This sentence is returned (on the Control Port) for every <strong>$PMVXG</strong> and <strong>$XXGPQ</strong> sentence that is received. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Sentence ID</td> + <td> </td> + <td>Char</td> + <td> </td> + </tr> + <tr> + <td>2</td> + <td>Accept/Reject Status</td> + <td> </td> + <td>Int</td> + <td>0=Sentence Accepted<br> + 1=Bad Checksum<br> + 2=Illegal Value<br> + 3=Unrecognized ID<br> + 4=Wrong # of fields<br> + 5=Required Data Field Missing<br> + 6=Requested Sentence Unavailable</td> + </tr> + <tr> + <td>3</td> + <td>Bad Field Index</td> + <td> </td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>4</td> + <td>Requested Sentence ID (If field #1 = GPQ)</td> + <td> </td> + <td>Char</td> + <td> </td> + </tr> + </table> + Example:<br> + <code>$PMVXG,101,GPQ,0,,030*0D</code> + <hr> + <h3><a name="output_523">$PMVXG,523</a></h3> + <h4>Time Recovery Configuration</h4> + This sentence contains the configuration of the time recovery function of the receiver. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Time Recovery Mode</td> + <td> </td> + <td>Char</td> + <td>D=Dynamic<br> + S=Static<br> + K=Known Position<br> + N=No Time Recovery</td> + </tr> + <tr> + <td>2</td> + <td>Time Synchronization</td> + <td> </td> + <td>Char</td> + <td>U=UTC Time<br> + G=GPS Time</td> + </tr> + <tr> + <td>3</td> + <td>Time Mark Mode</td> + <td> </td> + <td>Char</td> + <td>A=Always Output Time Pulse<br> + V=Only when Valid</td> + </tr> + <tr> + <td>4</td> + <td>Maximum Time Error for which a time mark will be considered valid</td> + <td>Nsec</td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>5</td> + <td>User Time Bias</td> + <td>Nsec</td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>6</td> + <td>Time Message Control</td> + <td> </td> + <td>Int</td> + <td>0=No Message<br> + 1=830 to Control Port<br> + 2=830 to Equipment Port</td> + </tr> + <tr> + <td>7</td> + <td>Not Used</td> + <td> </td> + <td> </td> + <td> </td> + </tr> + </table> + Example:<br> + <code>$PMVXG,523,S,U,A,0500,000000,1,0*23</code> + <hr> + <h3><a name="output_830">$PMVXG,830</a></h3> + <h4>Time Recovery Results</h4> + This sentence is output approximately 1 second preceding the 1PPS output. It indicates the exact time of the next pulse, whether or not the time mark will be valid (based on operator-specified error tolerance), the time to which the pulse is synchronized, the receiver operating mode, and the time error of the <strong>last</strong> 1PPS output. The leap second flag (Field #11) is not output by older receivers. + <p></p> + <table border> + <tr> + <th>Field</th> + <th>Description</th> + <th>Units</th> + <th>Format</th> + <th>Range</th> + </tr> + <tr> + <td>1</td> + <td>Time Mark Valid</td> + <td> </td> + <td>Char</td> + <td>T=Valid<br> + F=Not Valid</td> + </tr> + <tr> + <td>2</td> + <td>Year</td> + <td> </td> + <td>Int</td> + <td>1993-</td> + </tr> + <tr> + <td>3</td> + <td>Month</td> + <td> </td> + <td>Int</td> + <td>1-12</td> + </tr> + <tr> + <td>4</td> + <td>Day</td> + <td>Nsec</td> + <td>Int</td> + <td>1-31</td> + </tr> + <tr> + <td>5</td> + <td>Time</td> + <td>HH:MM:SS</td> + <td>Int</td> + <td>00:00:00-23:59:59</td> + </tr> + <tr> + <td>6</td> + <td>Time Synchronization</td> + <td> </td> + <td>Char</td> + <td>U=UTC<br> + G=GPS</td> + </tr> + <tr> + <td>7</td> + <td>Operating Mode</td> + <td> </td> + <td>Char</td> + <td>D=Dynamic<br> + S=Static<br> + K=Known Position</td> + </tr> + <tr> + <td>8</td> + <td>Oscillator Offset - estimate of oscillator frequency error</td> + <td>PPB</td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>9</td> + <td>Time Mark Error of last pulse</td> + <td>Nsec</td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>10</td> + <td>User Time Bias</td> + <td>Nsec</td> + <td>Int</td> + <td> </td> + </tr> + <tr> + <td>11</td> + <td>Leap Second Flag - indicates that a leap second will occur. This value is usually zero except during the week prior to a leap second occurrence, when this value will be set to +/-1. A value of +1 indicates that GPS time will be 1 second further ahead of UTC time.</td> + <td> </td> + <td>Int</td> + <td>-1,0,1</td> + </tr> + </table> + Example:<br> + <code>$PMVXG,830,T,1998,10,12,15:30:46,U,S,000298,00003,000000,01*02</code> + <hr> + <script type="text/javascript" language="javascript" src="../scripts/footer.txt"></script> + </body> + +</html>
\ No newline at end of file |