diff options
Diffstat (limited to 'html/drivers')
42 files changed, 2119 insertions, 1539 deletions
diff --git a/html/drivers/driver1.html b/html/drivers/driver1.html index 9c58265c908b..4518b72d3208 100644 --- a/html/drivers/driver1.html +++ b/html/drivers/driver1.html @@ -1,50 +1,50 @@ <!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>Undisciplined Local Clock</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Undisciplined Local Clock</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.1.<i>u</i><br> - Reference ID: <tt>LCL</tt><br> - Driver ID: <tt>LOCAL</tt></p> - <h4>Description</h4> - <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> - <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>Specifies the frequency offset calibration factor, in parts per million, with default 0.0. - <dt><tt>stratum <i>number</i></tt> - <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 3. - <dt><tt>refid <i>string</i></tt> - <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>LCL</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> - <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 +<head> +<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> +<meta name="generator" content="HTML Tidy, see www.w3.org"> +<title>Undisciplined Local Clock</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>Undisciplined Local Clock</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> +Last update: + <!-- #BeginDate format:En2m -->9-May-2014 08:34<!-- #EndDate --> + UTC</p> +<hr> +<h4>Synopsis</h4> +<p>Address: 127.127.1.<i>u</i><br> + Reference ID: <tt>LOCL</tt><br> + Driver ID: <tt>LOCAL</tt></p> +<h4>Description</h4> +<p>Note: <strong>We recommend against using this driver.</strong> A much more flexible replacement is described on the <a href="../orphan.html">Orphan Mode</a> page.</p> +<p>This driver was 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 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 elsewhere in the network are available. To further protect the Internet infrastructure from accidental or malicious exposure to this driver, the driver is disabled 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> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Specifies the frequency offset calibration factor, in parts per million, with default 0.0.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 5.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>LOCL</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> +</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> diff --git a/html/drivers/driver10.html b/html/drivers/driver10.html index 20391d3b780d..1dd56c102713 100644 --- a/html/drivers/driver10.html +++ b/html/drivers/driver10.html @@ -1,53 +1,53 @@ <!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="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.</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 +<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> +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> +<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></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Set for computers that listen-only.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> +</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> diff --git a/html/drivers/driver11.html b/html/drivers/driver11.html index e7c370a5920c..f3c9a81e8a79 100644 --- a/html/drivers/driver11.html +++ b/html/drivers/driver11.html @@ -1,29 +1,30 @@ <!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="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>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 +<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> +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> +<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) @@ -32,10 +33,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 @@ -45,41 +46,40 @@ 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> - -</html>
\ No newline at end of file +<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></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>GPS</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> +</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> diff --git a/html/drivers/driver12.html b/html/drivers/driver12.html index 6d0b38ab76fa..3b6fc1565cb8 100644 --- a/html/drivers/driver12.html +++ b/html/drivers/driver12.html @@ -1,49 +1,49 @@ <!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="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>KSI/Odetics TPRO/S IRIG Interface</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>KSI/Odetics TPRO/S IRIG Interface</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.12.<i>u</i><br> - Reference ID: <tt>IRIG</tt><br> - Driver ID: <tt>IRIG_TPRO</tt><br> - TPRO Device: <tt>/dev/tpro<i>u</i></tt><br> - Requires: KSI/Odetics device driver, <tt>/usr/include/sys/tpro.h</tt> header file</p> - <h4>Description</h4> - <p>This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder, which is a module connected directly to the SBus of a Sun workstation. The module works with the IRIG-B signal generated by several radio clocks, including those made by Arbiter, Austron, Odetics, Spectracom and TrueTime, among others, although it is generally an add- on option. In the case of the TPRO-SAT, the module is an integral part of a GPS receiver, which serves as the primary timing source.</p> - <p>Using the TPRO interface as a NTP reference clock provides precision time only to ntpd and its clients. With suitable kernel modifications, it is possible to use the TPRO as the CPU system clock, avoiding errors introduced by the CPU clock oscillator wander. See the <a href="../kern.html">A Kernel Model for Precision Timekeeping </a>page for further details.</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>IRIG</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> - <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 +<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>KSI/Odetics TPRO/S IRIG Interface</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>KSI/Odetics TPRO/S IRIG Interface</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> +<hr> +<h4>Synopsis</h4> +<p>Address: 127.127.12.<i>u</i><br> + Reference ID: <tt>IRIG</tt><br> + Driver ID: <tt>IRIG_TPRO</tt><br> + TPRO Device: <tt>/dev/tpro<i>u</i></tt><br> + Requires: KSI/Odetics device driver, <tt>/usr/include/sys/tpro.h</tt> header file</p> +<h4>Description</h4> +<p>This driver supports the KSI/Odetics TPRO and TPRO-SAT IRIG-B Decoder, which is a module connected directly to the SBus of a Sun workstation. The module works with the IRIG-B signal generated by several radio clocks, including those made by Arbiter, Austron, Odetics, Spectracom and TrueTime, among others, although it is generally an add- on option. In the case of the TPRO-SAT, the module is an integral part of a GPS receiver, which serves as the primary timing source.</p> +<p>Using the TPRO interface as a NTP reference clock provides precision time only to ntpd and its clients. With suitable kernel modifications, it is possible to use the TPRO as the CPU system clock, avoiding errors introduced by the CPU clock oscillator wander. See the <a href="../kern.html">A Kernel Model for Precision Timekeeping </a>page for further details.</p> +<h4>Fudge Factors</h4> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>IRIG</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> +</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> diff --git a/html/drivers/driver16.html b/html/drivers/driver16.html index 95308ba1621a..74a3bd640db8 100644 --- a/html/drivers/driver16.html +++ b/html/drivers/driver16.html @@ -2,30 +2,33 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="GENERATOR" content="Mozilla/4.6 [en] (Win95; U) [Netscape]"> - <meta name="Author" content="Ganesh Ramasivan"> - <title>Bancomm bc635VME Time and Frequency Processor</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.6 [en] (Win95; U) [Netscape]"> + <meta name="Author" content="Ganesh Ramasivan"> + <title>Bancomm bc635VME Time and Frequency Processor</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>bc635VME/bc350VXI Time and Frequency Processor</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.16.<i>u</i><br> - Reference ID: BTFP<br> - Driver ID: GPS_BANCOMM<br> - Bancomm Device <tt>/dev/btfp0</tt><br> - Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p> - <h4>Description</h4> - <p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p> - <p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p> - <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>bc635VME/bc350VXI Time and Frequency Processor</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> + <hr> + <h4>Synopsis</h4> + <p>Address: 127.127.16.<i>u</i><br> + Reference ID: BTFP<br> + Driver ID: GPS_BANCOMM<br> + Bancomm Device <tt>/dev/btfp0</tt><br> + Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x</p> + <h4>Description</h4> + <p>This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.</p> + <p>Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.</p> + <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 +</html> diff --git a/html/drivers/driver18.html b/html/drivers/driver18.html index a4dc76924462..02fb5d2d8b94 100644 --- a/html/drivers/driver18.html +++ b/html/drivers/driver18.html @@ -1,82 +1,82 @@ <!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="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>NIST/USNO/PTB Modem Time Services</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>NIST/USNO/PTB Modem Time Services</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.18.<i>u</i><br> - Reference ID: <tt>NIST | USNO | PTB | WWVB</tt><br> - Driver ID: <tt>ACTS_MODEM</tt><br> - Serial Port: <tt>/dev/acts<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> - Features: <tt>tty_clk</tt><br> - Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control and a dial-out (cua) device.</p> - <h4>Description</h4> - <p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p> - <p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p> - <p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p> - <p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpdc</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p> - <p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpdc</tt>.</p> - <p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p> - <p>Ordinarily, the serial port is connected to a modem; however, if fudge <tt>flag3</tt> is set, it can be connected directly to a Spectracom WWV or GPS radio for testing or calibration. The Spectracom radio can be connected via a modem if the radio is connfigured to send time codes continuoulsly at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p> - <p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p> - <h4>US Phone Numbers and Formats</h4> - <p>Note: Phone numbers include the entire Hayes modem command, including the <tt>ATDT</tt> and other control codes as may be necessary. For most cases only the <tt>ATDT</tt> may be necessary.</p> - <p><a href="http://www.boulder.nist.gov/timefreq">National Institute of Science and Technology (NIST)</a></p> - <p>Phone: (303) 494-4774 (Boulder, CO); (808) 335-4721 (Hawaii)</p> - <p><a href="http://www.boulder.nist.gov/timefreq/service/acts.htm">Data Format</a></p> - <p><tt>National Institute of Standards and Technology<br> - Telephone Time Service, Generator 3B<br> - Enter question mark "?" for HELP<br> - MJD YR MO DA H M S ST S UT1 msADV <OTM><br> - 47999 90-04-18 21:39:15 50 0 +.1 045.0 UTC(NIST) *<br> - 47999 90-04-18 21:39:16 50 0 +.1 045.0 UTC(NIST) #<br> - ...</tt></p> - <p><tt>MJD</tt>, <tt>YR</tt>, <tt>ST</tt>, <tt>UT1</tt> and <tt>UTC(NIST)</tt> are not used by this driver. The <tt><OTM></tt> on-time character "<tt>*</tt>" changes to "<tt>#</tt>" when the delay correction is valid.</p> - <p><a href="http://tycho.usno.navy.mil">US Naval Observatory (USNO)</a></p> - <p>Phone: (202) 762-1594 (Washington, DC); (719) 567-6742 (Boulder, CO)</p> - <p><a href="http://tycho.usno.navy.mil/modem_time.html">Data Format</a> (two lines, repeating at one-second intervals)</p> - <p><tt>jjjjj nnn hhmmss UTC</tt></p> - <p>* on-time character for previous timecode message<br> - jjjjj modified Julian day number (not used)<br> - nnn day of year<br> - hhmmss second of day</p> - <p><a href="tf582_4.html">European Phone Numbers and Formats</a></p> - <p><a href="http://www.spectracomcorp.com">Spectracom GPS and WWVB Receivers</a></p> - <p>If a modem is connected to a Spectracom receiver, this driver will call it and retrieve the time in one of two formats, 0 and 2. Ordinarily, the receiver requires a <tt>T</tt> in order to return the timecode. As this driver does not send data via the modem, it must either be configured in continuous mode or be polled by another local driver.</p> - <h4>Monitor Data</h4> - <p>The received timecode is written as-is to the <tt>clockstats</tt> file along with the Hayes connection and hangup commands and result codes.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <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>Set by the driver to (one of) <tt>NIST</tt>, <tt>USNO</tt>, <tt>PTB</tt> or <tt>WWVB</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Initiate a call if 1. Automatically reset by program. - <dt><tt>flag2 0 | 1</tt> - <dd>Enables port locking if 1, disables if 0 (default). - <dt><tt>flag3 0 | 1</tt> - <dd>Enables direct connection if 1, or modem if 0 (default). If set, the driver will send a single character 'T' at every poll event. - <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 +<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/USNO/PTB Modem Time Services</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>NIST/USNO/PTB Modem Time Services</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->1-Dec-2012 10:44<!-- #EndDate --> + UTC</p> +<hr> +<h4>Synopsis</h4> +<p>Address: 127.127.18.<i>u</i><br> + Reference ID: <tt>NIST | USNO | PTB | WWVB</tt><br> + Driver ID: <tt>ACTS_MODEM</tt><br> + Serial Port: <tt>/dev/acts<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> + Features: <tt>tty_clk</tt><br> + Requires: <tt>/usr/include/sys/termios.h</tt> header file with modem control and a dial-out (cua) device.</p> +<h4>Description</h4> +<p>This driver supports the US (NIST and USNO) and European (PTB (Germany), NPL (UK), etc.) modem time services, as well as Spectracom GPS and WWVB receivers connected via a modem. The driver periodically dials a number from a telephone list, receives the timecode data and calculates the local clock correction. It is designed primarily for backup when neither a radio clock nor connectivity to Internet time servers are available. It can also be configured to operate full period.</p> +<p>For best results the indicated time must be corrected for the modem and telephone circuit propagation delays, which can reach 200 ms or more. For the NIST service, corrections are determined automatically by measuring the roundtrip delay of echoed characters. With this service the absolute accuracy is typically a millisecond or two. Corrections for the other services must be determined by other means. With these services variations from call to call and between messages during a call are typically a few milliseconds, occasionally higher.</p> +<p>This driver requires a 9600-bps modem with a Hayes-compatible command set and control over the modem data terminal ready (DTR) control line. The actual line speed ranges from 1200 bps with USNO to 14,400 bps with NIST. The modem setup string is hard-coded in the driver and may require changes for nonstandard modems or special circumstances.</p> +<p>There are three modes of operation selected by the <tt>mode</tt> keyword in the <tt>server</tt> configuration command. In manual mode (2) the calling program is initiated by setting fudge <tt>flag1</tt>. This can be done manually using <tt>ntpq</tt>, or by a cron job. In auto mode (0) <tt>flag1</tt> is set at each poll event. In backup mode (1) <tt>flag1</tt> is set at each poll event, but only if no other synchronization sources are available.</p> +<p>When <tt>flag1</tt> is set, the calling program dials the first number in the list specified by the <tt>phone</tt> command. If the call fails for any reason, the program dials the second number and so on. The phone number is specified by the Hayes ATDT prefix followed by the number itself, including the prefix and long-distance digits and delay code, if necessary. The <tt>flag1</tt> is reset and the calling program terminated if (a) valid clock update has been determined, (b) no more numbers remain in the list, (c) a device fault or timeout occurs or (d) fudge <tt>flag1</tt> is reset manually using <tt>ntpq</tt>.</p> +<p>The driver automatically recognizes the message format of each modem time service. It selects the parsing algorithm depending on the message length. There is some hazard should the message be corrupted. However, the data format is checked carefully and only if all checks succeed is the message accepted. Corrupted lines are discarded without complaint. Once the service is known, the reference identifier for the driver is set to NIST, USNO, PTB or WWVB as appropriate.</p> +<p>The Spectracom radio can be connected via a modem if the radio is configured to send time codes continuously at 1-s intervals. In principle, fudge <tt>flag2</tt> enables port locking, allowing the modem to be shared when not in use by this driver. At least on Solaris with the current NTP I/O routines, this results in lots of ugly error messages.</p> +<p>The <tt>minpoll</tt> and <tt>maxpoll</tt> keywords of the server configuration command can be used to limit the intervals between calls. The recommended settings are 12 (1.1 hours) for <tt>minpoll</tt> and 17 (36 hours) for <tt>maxpoll</tt>. Ordinarily, the poll interval will start at <tt>minpoll</tt> and ramp up to <tt>maxpoll</tt> in a day or two.</p> +<h4>US Phone Numbers and Formats</h4> +<p>Note: Phone numbers include the entire Hayes modem command, including the <tt>ATDT</tt> and other control codes as may be necessary. For most cases only the <tt>ATDT</tt> may be necessary.</p> +<p><a href="http://www.boulder.nist.gov/timefreq">National Institute of Science and Technology (NIST)</a></p> +<p>Phone: (303) 494-4774 (Boulder, CO); (808) 335-4721 (Hawaii)</p> +<p><a href="http://www.boulder.nist.gov/timefreq/service/acts.htm">Data Format</a></p> +<p><tt>National Institute of Standards and Technology<br> + Telephone Time Service, Generator 3B<br> + Enter question mark "?" for HELP<br> + MJD YR MO DA H M S ST S UT1 msADV <OTM><br> + 47999 90-04-18 21:39:15 50 0 +.1 045.0 UTC(NIST) *<br> + 47999 90-04-18 21:39:16 50 0 +.1 045.0 UTC(NIST) #<br> + ...</tt></p> +<p><tt>MJD</tt>, <tt>YR</tt>, <tt>ST</tt>, <tt>UT1</tt> and <tt>UTC(NIST)</tt> are not used by this driver. The <tt><OTM></tt> on-time character "<tt>*</tt>" changes to "<tt>#</tt>" when the delay correction is valid.</p> +<p><a href="http://tycho.usno.navy.mil">US Naval Observatory (USNO)</a></p> +<p>Phone: (202) 762-1594 (Washington, DC); (719) 567-6742 (Boulder, CO)</p> +<p><a href="http://tycho.usno.navy.mil/modem_time.html">Data Format</a> (two lines, repeating at one-second intervals)</p> +<p><tt>jjjjj nnn hhmmss UTC</tt></p> +<p>* on-time character for previous timecode message<br> + jjjjj modified Julian day number (not used)<br> + nnn day of year<br> + hhmmss second of day</p> +<p><a href="tf582_4.html">European Phone Numbers and Formats</a></p> +<p><a href="http://www.spectracomcorp.com">Spectracom GPS and WWVB Receivers</a></p> +<p>If a modem is connected to a Spectracom receiver, this driver will call it and retrieve the time in one of two formats, 0 and 2. Ordinarily, the receiver requires a <tt>T</tt> in order to return the timecode. As this driver does not send data via the modem, it must either be configured in continuous mode or be polled by another local driver.</p> +<h4>Monitor Data</h4> +<p>The received timecode is written as-is to the <tt>clockstats</tt> file along with the Hayes connection and hang-up commands and result codes.</p> +<h4>Fudge Factors</h4> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Set by the driver to (one of) <tt>NIST</tt>, <tt>USNO</tt>, <tt>PTB</tt> or <tt>WWVB</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Initiate a call if 1. Automatically reset by program.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Enables port locking if 1, disables if 0 (default).</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> +</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> diff --git a/html/drivers/driver19.html b/html/drivers/driver19.html index e498969f10c9..2c8278fb03a7 100644 --- a/html/drivers/driver19.html +++ b/html/drivers/driver19.html @@ -1,59 +1,59 @@ <!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="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. 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> +<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> +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> +<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> - -</html>
\ No newline at end of file +<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></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWV</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Not used by this driver</dd> +</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> diff --git a/html/drivers/driver2.html b/html/drivers/driver2.html deleted file mode 100644 index 20bad64a259b..000000000000 --- a/html/drivers/driver2.html +++ /dev/null @@ -1,67 +0,0 @@ -<!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="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>Trak 8820 GPS Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Trak 8820 GPS Receiver</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.2.<i>u</i><br> - Reference ID: <tt>GPS</tt><br> - Driver ID: <tt>GPS_TRAK</tt><br> - Serial Port: <tt>/dev/trak<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 Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns 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>For best accuracy, this radio requires the <tt>tty_clk</tt> line discipline, which captures a timestamp at the <tt>*</tt> on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the <tt>\r</tt> ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.</p> - <p>Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.</p> - <p>In operation, this driver sends a <tt>RQTS\r</tt> request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:</p> - <pre>*RQTS U,ddd:hh:mm:ss.0,q<cr><lf> -on-time = '*' -ddd = day of year -hh:mm:ss = hours, minutes, seconds -q = quality indicator (phase error), 0-6: - 0 > 20 us - 6 > 10 us - 5 > 1 us - 4 > 100 ns - 3 > 10 ns - 2 < 10 ns</pre> - The alarm condition is indicated by <tt>0</tt> at <tt>Q</tt>, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed. - <p>The continuous time mode is disabled using the <tt>RQTX\r</tt> request, following which the radio sends a <tt>RQTX DONE<cr><lf></tt> response. In the normal mode, other control and status requests are effective, including the leap-second status request <tt>RQLS<cr></tt>. The radio responds with <tt>RQLS yy,mm,dd<cr><lf></tt>, where <tt>yy,mm,dd</tt> are the year, month and day. Presumably, this gives the epoch of the next leap second, <tt>RQLS 00,00,00</tt> if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.</p> - <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> - <p></p> - <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>Not used by this driver. - <p>Additional Information</p> - <p><a href="../refclock.html">Reference Clock Drivers</a></p> - </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/driver20.html b/html/drivers/driver20.html index 9b871a937f09..6391e869359f 100644 --- a/html/drivers/driver20.html +++ b/html/drivers/driver20.html @@ -1,105 +1,432 @@ <!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>Generic NMEA GPS Receiver</title> + <!-- Changed by: Harlan &, 31-Mar-2014 --> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + <style type="text/css"> + table.dlstable { font-size:85%; } + td.ttf{ font-family:Courier; font-weight:bold; } + </style></head> -<html> - - <head> - <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> - <title>Generic NMEA GPS Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Generic NMEA GPS Receiver</h3> - <hr> - <h4>Synopsis</h4> - <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 - 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, $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,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> - - 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) - LON - Longitude (yyyyy.yy) - LON_REF - Longitude direction (E = East, W = West) - SPD - Speed over ground. (knots) (x.x) - HDG - Heading/track made good (degrees True) (x.x) - 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) - SAT_USED - Number Satellites used in solution - HDOP - Horizontal Dilution of Precision - ALT - Antenna Altitude - ALT_UNIT - Altitude Units (Metres/Feet) - GEO - Geoid/Elipsoid separation - G_UNIT - Geoid units (M/F) - D_AGE - Age of last DGPS Fix - D_REF - Reference ID of DGPS station - 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> - -<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> - <p>Now switch only $GPRMC on by sending it the following string.</p> - <pre>"$PGRMO,GPRMC,1<cr><lf>"</pre> - <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 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 PPS time offset calibration factor, in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <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>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>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> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> - -</html> + + + <body> + <h3>Generic NMEA GPS Receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->31-Mar-2014 03:55<!-- #EndDate --> + UTC</p> + <hr> + <h4>Synopsis</h4> + + <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 - 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)<br> + Features: <tt>tty_clk</tt> + </p> + + <h4>Description</h4> + + <p> + This driver supports GPS receivers with + the <tt>$GPRMC</tt>, <tt>$GPGLL</tt>, <tt>$GPGGA</tt>, <tt>$GPZDA</tt> + and <tt>$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 μ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. + </p> + <p> + The various GPS sentences that this driver recognises look like this:<br> + (others quietly ignored) + </p> + + <p><table class="dlstable" border="1"> + <caption>Accepted NMEA sentences</caption> + <tbody><tr> + <th>Sentence</th> + <th>Vendor</th> + </tr><tr> + <td class="ttf">$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf></td> + </tr><tr> + <td class="ttf">$GPGLL,LAT,LAT_REF,LON,LON_REF,UTC,POS_STAT*CS<cr><lf></td> + </tr><tr> + <td class="ttf">$GPGGA,UTC,LAT,LAT_REF,LON,LON_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS<cr><lf></td> + </tr><tr> + <td class="ttf">$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS<cr><lf></td> + </tr><tr> + <td class="ttf">$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf></td> + <td>Accord</td> + </tr> + </tbody></table></p> + + <p><table class="dlstable" border="1"> + <caption>NMEA data items</caption> + <tbody><tr> + <th>Symbol</th> + <th>Meaning and Format</th> + </tr> + + <tr> + <td class="ttf">UTC</td> + <td>Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.fff])</td> + </tr><tr> + <td class="ttf">POS_STAT</td> + <td>Position status. (A = Data valid, V = Data invalid)</td> + </tr><tr> + <td class="ttf">LAT</td> + <td>Latitude (llll.ll)</td> + </tr><tr> + <td class="ttf">LAT_REF</td> + <td>Latitude direction. (N = North, S = South)</td> + </tr><tr> + <td class="ttf">LON</td> + <td>Longitude (yyyyy.yy)</td> + </tr><tr> + <td class="ttf">LON_REF</td> + <td>Longitude direction (E = East, W = West)</td> + </tr><tr> + <td class="ttf">SPD</td> + <td>Speed over ground. (knots) (x.x)</td> + </tr><tr> + <td class="ttf">HDG</td> + <td>Heading/track made good (degrees True) (x.x)</td> + </tr><tr> + <td class="ttf">DATE</td> + <td>Date (ddmmyy)</td> + </tr><tr> + <td class="ttf">MAG_VAR</td> + <td>Magnetic variation (degrees) (x.x)</td> + </tr><tr> + <td class="ttf">MAG_REF</td> + <td>Magnetic variation (E = East, W = West)</td> + </tr><tr> + <td class="ttf">FIX_MODE</td> + <td>Position Fix Mode (0 = Invalid, >0 = Valid)</td> + </tr><tr> + <td class="ttf">SAT_USED</td> + <td>Number of Satellites used in solution</td> + </tr><tr> + <td class="ttf">HDOP</td> + <td>Horizontal Dilution of Precision</td> + </tr><tr> + <td class="ttf">ALT</td> + <td>Antenna Altitude</td> + </tr><tr> + <td class="ttf">ALT_UNIT</td> + <td>Altitude Units (Metres/Feet)</td> + </tr><tr> + <td class="ttf">GEO</td> + <td>Geoid/Elipsoid separation</td> + </tr><tr> + <td class="ttf">G_UNIT</td> + <td>Geoid units (M/F)</td> + </tr><tr> + <td class="ttf">D_AGE</td> + <td>Age of last DGPS Fix</td> + </tr><tr> + <td class="ttf">D_REF</td> + <td>Reference ID of DGPS station</td> + </tr><tr> + <td class="ttf">GPSTIME</td> + <td>Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)]. (hhmmss[.f])</td> + </tr><tr> + <td class="ttf">DD</td> + <td>Day of the month (1-31)</td> + </tr><tr> + <td class="ttf">MM</td> + <td>Month of the year (1-12)</td> + </tr><tr> + <td class="ttf">YYYY</td> + <td>Year</td> + </tr><tr> + <td class="ttf">AA.BB</td> + <td>Denotes the signal strength (should be < 05.00)</td> + </tr><tr> + <td class="ttf">V</td> + <td>GPS sync status<br> + '0' => INVALID time,<br> + '1' => accuracy of +/- 20ms,<br> + '2' => accuracy of +/- 100ns</td> + </tr><tr> + <td class="ttf">CS</td> + <td> Checksum</td> + </tr><tr> + <td class="ttf"><cr><lf></td> + <td>Sentence terminator.</td> + </tr> + </tbody></table></p> + + + <h4>The 'mode' byte</h4> + + <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> + </p> + + <table border="1"> + <caption>mode byte bits and bit groups</caption> + <tbody><tr> + <th align="center">Bit</th> + <th align="center">Decimal</th> + <th align="center">Hex</th> + <th align="left">Meaning</th> + </tr> + + <tr> + <td align="center">0</td> + <td align="center">1</td> + <td align="center">1</td> + <td>process <tt>$GPMRC</tt></td> + </tr><tr> + <td align="center">1</td> + <td align="center">2</td> + <td align="center">2</td> + <td>process <tt>$GPGGA</tt></td> + </tr><tr> + <td align="center">2</td> + <td align="center">4</td> + <td align="center">4</td> + <td>process <tt>$GPGLL</tt></td> + </tr><tr> + <td align="center">3</td> + <td align="center">8</td> + <td align="center">8</td> + <td>process <tt>$GPZDA</tt> or <tt>$GPZDG</tt></td> + </tr><tr> + <td rowspan="6" align="center">4-6</td> + <td align="center">0</td> + <td align="center">0</td> + <td>linespeed 4800 bps</td> + </tr><tr> + <td align="center">16</td> + <td align="center">0x10</td> + <td>linespeed 9600 bps</td> + </tr><tr> + <td align="center">32</td> + <td align="center">0x20</td> + <td>linespeed 19200 bps</td> + </tr><tr> + <td align="center">48</td> + <td align="center">0x30</td> + <td>linespeed 38400 bps</td> + </tr><tr> + <td align="center">64</td> + <td align="center">0x40</td> + <td>linespeed 57600 bps</td> + </tr><tr> + <td align="center">80</td> + <td align="center">0x50</td> + <td>linespeed 115200 bps</td> + </tr><tr> + <td align="center">7</td> + <td align="center">128</td> + <td align="center">0x80</td> + <td>Write the sub-second fraction of the receive time stamp to the + clockstat file for all recognised NMEA sentences. This can be used to + get a useful value for fudge time2.<br><strong>Caveat:</strong> This + will fill your clockstat file rather fast. Use it only temporarily to + get the numbers for the NMEA sentence of your choice.</td> + </tr> + </tr><tr> + <td align="center">8</td> + <td align="center">256</td> + <td align="center">0x100</td> + <td>process <tt>$PGRMF</tt></td> + </tr><tr> + <td align="center">9-15</td> + <td align="center"></td> + <td align="center">0xFE00</td> + <td>reserved - leave 0</td> + </tr><tr> + <td align="center">16</td> + <td align="center">65536</td> + <td align="center">0x10000</td> + <td>Append extra statistics to the clockstats line. + Details below.</td> + </tr> + </tbody></table> + + + <p> + The default (mode 0) is to process all supported sentences at a linespeed + of 4800 bps, which results in the first one received and recognised in + each cycle being used. If only specific sentences should be + recognised, then the mode byte must be chosen to enable only the selected + ones. Multiple sentences may be selected by adding their mode bit + values, but of those enabled still only the first received sentence in a + cycle will be used. Using more than one sentence per cycle is + impossible, because + </p><ul> + <li>there is only <a href="#fudgetime2">fudge time2</a> available to + compensate for transmission delays but every sentence would need a + different one and + </li><li>using more than one sentence per cycle overstuffs the internal data + filters. + </li></ul> + The driver uses 4800 bits per second by default, but faster bitrates can + be selected using bits 4 to 6 of the mode field. + <p></p> + + <p> + <strong>Caveat:</strong> Using higher line speeds does not necessarily + increase the precision of the timing device. Higher line speeds are + not necessarily helpful for the NMEA driver, either. They can be + used to accomodate for an amount of data that does not fit into a + 1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely + to cause trouble with the serial line driver since NMEA supports no + protocol handshake. Any device that is exclusively used for time + synchronisation purposes should be configured to transmit the relevant + data only, e.g. one <tt>$GPRMC</tt> or <tt>$GPZDA</tt> per second, at a + linespeed of 4800 bps or 9600 bps. + </p> + + <h4>Monitor Data</h4> + + <p>The last GPS sentence that is accepted or rejected is written to the + clockstats file and available with <code>ntpq -c clockvar</code>. + (Logging the rejected sentences lets you see/debug why they were rejected.) + Filtered sentences are not logged.</p> + + <p> + If the 0x10000 mode bit is on and clockstats is enabled, several extra + counters will be appended to the NMEA sentence that gets logged. + For example: +<pre> +56299 76876.691 127.127.20.20 $GPGGA,212116.000,3726.0785,N,12212.2605,W,1,05,2.0,17.0,M,-25.7,M,,0000*5C 228 64 0 0 64 0 +</pre> + </p> + + <table border="1"> + <caption>Clockstats</caption> + <tbody><tr> + <th align="center">Column</th> + <th align="center">Sample</th> + <th align="left">Meaning</th> + </tr> + + <tr> + <td align="center">1</td> + <td align="center">56299</td> + <td>MJD</td> + </tr><tr> + <td align="center">2</td> + <td align="center">76876.691</td> + <td>Time of day in seconds</td> + </tr><tr> + <td align="center">3</td> + <td align="center">127.127.20.20</td> + <td>IP Address from server config line</td> + </tr><tr> + <td align="center">4</td> + <td align="center">$GPGGA,...0*5C</td> + <td>NMEA Sentence</td> + </tr><tr> + <td align="center">5</td> + <td align="center">228</td> + <td>Number of sentences received</td> + </tr><tr> + <td align="center">6</td> + <td align="center">64</td> + <td>Number of sentences accepted and used for timekeeping</td> + </tr><tr> + <td align="center">7</td> + <td align="center">0</td> + <td>Number of sentences rejected because they were marked invalid (poor signal)</td> + </tr><tr> + <td align="center">8</td> + <td align="center">0</td> + <td>Number of sentences rejected because of bad checksum or invalid date/time</td> + </tr><tr> + <td align="center">9</td> + <td align="center">64</td> + <td>Number of sentences filtered by mode bits or same second</td> + </tr><tr> + <td align="center">10</td> + <td align="center">0</td> + <td>Number of PPS pulses used, overrides NMEA sentences</td> + </tr> + </tbody></table> + + Sentences like $GPGSV that don't contain the time will get + counted in the total but otherwise ignored. + + <p> + <a href="https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks">Configuring + NMEA Refclocks</a> might give further useful hints for specific hardware + devices that exhibit strange or curious behaviour. + </p> + + <p> + To make a specific setting, select the corresponding decimal values from + the mode byte table, add them all together and enter the resulting + decimal value into the clock configuration line. + </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> + <p>Now switch only $GPRMC on by sending it the following string.</p> + <pre>"$PGRMO,GPRMC,1<cr><lf>"</pre> + + <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>Fudge Factors</h4> + + <dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><a name="fudgetime2"><tt>time2 <i>time</i></tt></a></dt> + <dd>Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default + 0.0.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with + default <tt>GPS</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the + falling edge if 1.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel + discipline if 1.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Obscures location in timecode: 0 for disable (default), 1 for enable.</dd> + </dl> + + <p>Additional Information</p> + <p><tt>flag1</tt>, <tt>flag2</tt>, and <tt>flag3</tt> are ignored under Windows.</p> + <p><a href="../refclock.html">Reference Clock Drivers</a></p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body></html> diff --git a/html/drivers/driver22.html b/html/drivers/driver22.html index 140568f98f26..6e01a38cfe3f 100644 --- a/html/drivers/driver22.html +++ b/html/drivers/driver22.html @@ -1,109 +1,98 @@ <!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>PPS Clock Discipline</title> +<!-- Changed by: Harlan &, 31-Mar-2014 --> <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> - +<p>Author: David L. Mills (mills@udel.edu)<br> + Last change: + <!-- #BeginDate format:En2m -->31-Mar-2014 07:46<!-- #EndDate --> + UTC</p> + <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 signal interface for PPS signal processing.</p> - + 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 (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. - <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>PPS</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <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>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> - <p>Reference</p> - <ol> - <li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp. - </ol> - <hr> - <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> - </body> - -</html>
\ No newline at end of file +<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 (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></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>PPS</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Specifies PPS capture on the rising (assert) pulse edge if 0 (default) or falling + (clear) pulse edge if 1. Not used under Windows - if the special <tt>serialpps.sys</tt> serial port driver is installed then the leading edge will <i>always</i> be used.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable. Not used under Windows - if the special <tt>serialpps.sys<\tt> serial port driver is used then kernel PPS will be available and used.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Record a timestamp once for each second if 1. Useful for constructing + Allan deviation plots.</dd> + . +</dl> +<h4>Additional Information</h4> +<p><a href="../refclock.html">Reference Clock Drivers</a></p> +<p>Reference</p> +<ol> + <li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp.</li> +</ol> +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +</body> +</html> diff --git a/html/drivers/driver26.html b/html/drivers/driver26.html index f840a03cf828..dc84cc154cb6 100644 --- a/html/drivers/driver26.html +++ b/html/drivers/driver26.html @@ -11,6 +11,9 @@ <body> <h3>Hewlett Packard 58503A GPS Receiver and HP Z3801A</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->5-Oct-2005 04:37<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.26.<i>u</i><br> diff --git a/html/drivers/driver27.html b/html/drivers/driver27.html index a425a9f681a1..91534ad0582a 100644 --- a/html/drivers/driver27.html +++ b/html/drivers/driver27.html @@ -11,6 +11,9 @@ <body> <h3>Arcron MSF Receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.27.<i>u</i><br> @@ -242,4 +245,4 @@ May 10 12:41:34 oolong ntpd[615]: ARCRON: sync finished, signal quality 3: OK, w <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/driver28.html b/html/drivers/driver28.html index 3458768a48f9..8c7fd802e623 100644 --- a/html/drivers/driver28.html +++ b/html/drivers/driver28.html @@ -5,12 +5,15 @@ <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>Shared memoy Driver</title> + <title>Shared Memory Driver</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> </head> <body> <h3>Shared Memory Driver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->8-Aug-2014 19:17<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.28.<i>u</i><br> @@ -22,49 +25,64 @@ <h4>Structure of shared memory-segment</h4> <pre>struct shmTime { - int mode; /* 0 - if valid set - * use values, - * clear valid - * 1 - if valid set - * if count before and after read of - * values is equal, - * use values - * clear valid - */ - int count; - time_t clockTimeStampSec; /* external clock */ - int clockTimeStampUSec; /* external clock */ - time_t receiveTimeStampSec; /* internal clock, when external value was received */ - int receiveTimeStampUSec; /* internal clock, when external value was received */ - int leap; - int precision; - int nsamples; - int valid; - int dummy[10]; + int mode; /* 0 - if valid is set: + * use values, + * clear valid + * 1 - if valid is set: + * if count before and after read of data is equal: + * use values + * clear valid + */ + volatile int count; + time_t clockTimeStampSec; + int clockTimeStampUSec; + time_t receiveTimeStampSec; + int receiveTimeStampUSec; + int leap; + int precision; + int nsamples; + volatile int valid; + unsigned clockTimeStampNSec; /* Unsigned ns timestamps */ + unsigned receiveTimeStampNSec; /* Unsigned ns timestamps */ + int dummy[8]; };</pre> <h4>Operation mode=0</h4> - <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> + <p>Each second, the value of <code>valid</code> 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 <code>valid</code> is cleared and <code>count</code> is bumped.</p> + <p>If not set, <code>count</code> is bumped.</p> <h4>Operation mode=1</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> + <p>Each second, <code>valid</code> in the shared memory-segment is checked:</p> + <p>If set, the <code>count</code> field of the record is remembered, and the values in the record (clockTimeStampSec, clockTimeStampUSec, receiveTimeStampSec, receiveTimeStampUSec, leap, precision) are read. Then, the remembered <code>count</code> is compared to current value of <code>count</code> 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 <code>valid</code> flag is cleared and <code>count</code> is bumped.</p> + <p>If not set, <code>count</code> is bumped</p> +<h4>Mode-independent postprocessing</h4> +After the time stamps have been successfully plucked from the SHM +segment, some sanity checks take place: +<ul> + <li>The receive time stamp of the SHM data must be in the last 5 + seconds before the time the data is processed. This helps in weeding + out stale data. + <li>If the absolute difference between remote and local clock + exceeds the limit (either <i>time2</i> or the default of 4hrs), then + the sample is discarded. This check is disabled when <i>flag1</i> is + set to 1. +</ul> <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. +It can work 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> - + <b>Note:</b> The GPSD client driver (type 46) uses the <i>gpsd</i> + client protocol to connect and talk to <i>gpsd</i>, but using the + SHM driver is the ancient way to have <i>gpsd</i> talk to <i>ntpd</i>. <h4>Clockstats</h4> If flag4 is set when the driver is polled, a clockstats record is written. @@ -99,13 +117,19 @@ Here is a sample showing the GPS reception fading out: <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. + <dd>Maximum allowed difference between remote and local + clock, in seconds. Values <1.0 or >86400.0 are ignored, and the + default value of 4hrs (14400s) is used instead. See also flag 1. <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>SHM</tt>. <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. + <dd><i>Skip</i> the difference limit check if set. Useful + for systems where the RTC backup cannot keep the time over + long periods without power and the SHM clock must be able + to force long-distance initial jumps. <i>Check</i> the + difference limit if cleared (default). <dt><tt>flag2 0 | 1</tt> <dd>Not used by this driver. <dt><tt>flag3 0 | 1</tt> diff --git a/html/drivers/driver29.html b/html/drivers/driver29.html index dde58ff68446..4939d8012ce3 100644 --- a/html/drivers/driver29.html +++ b/html/drivers/driver29.html @@ -10,6 +10,9 @@ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> <h1><font size="+2">Trimble Palisade and Thunderbolt Receivers</font> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> </h1> <table> @@ -1087,4 +1090,4 @@ Here is a link explaining the situation:<p> ; </body> -</html>
\ No newline at end of file +</html> diff --git a/html/drivers/driver3.html b/html/drivers/driver3.html index e5a06be55c0c..457e5a22be7e 100644 --- a/html/drivers/driver3.html +++ b/html/drivers/driver3.html @@ -1,28 +1,29 @@ <!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="Mozilla/4.01 [en] (Win95; I) [Netscape]"> - <title>PSTI/Traconex 1020 WWV/WWVH Receiver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>PSTI/Traconex 1020 WWV/WWVH Receiver</h3> - <hr> - <h4>Synopsis</h4> - <p>Address: 127.127.3.<i>u</i><br> - Reference ID: <tt>WWV</tt><br> - Driver ID: <tt>WWV_PST</tt><br> - Serial Port: <tt>/dev/wwv<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 PSTI 1010 and Traconex 1020 WWV/WWVH Receivers. No specific claim of accuracy is made for these receiver, but actual experience suggests that 10 ms would be a conservative assumption.</p> - <p>The dipswitches should be set for 9600 bps line speed, 24-hour day-of-year format and UTC time zone. Automatic correction for DST should be disabled. It is very important that the year be set correctly in the DIP-switches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year. As the there are only four dipswitches to set the year and the base value of zero correspondes to 1986, years beyond 2001 recycle with the value of zero corresponding to 2002. The propagation delay DIP-switches should be set according to the distance from the transmitter for both WWV and WWVH, as described in the instructions. While the delay can be set only to within 11 ms, the fudge time1 parameter can be used for vernier corrections.</p> - <p>Using the poll sequence <tt>QTQDQM</tt>, the response timecode is in three sections totalling 50 ASCII printing characters, as concatenated by the driver, in the following format:</p> - <pre> +<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>PSTI/Traconex 1020 WWV/WWVH Receiver</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>PSTI/Traconex 1020 WWV/WWVH Receiver</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> +Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> +<hr> +<h4>Synopsis</h4> +<p>Address: 127.127.3.<i>u</i><br> + Reference ID: <tt>WWV</tt><br> + Driver ID: <tt>WWV_PST</tt><br> + Serial Port: <tt>/dev/wwv<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 PSTI 1010 and Traconex 1020 WWV/WWVH Receivers. No specific claim of accuracy is made for these receiver, but actual experience suggests that 10 ms would be a conservative assumption.</p> +<p>The dipswitches should be set for 9600 bps line speed, 24-hour day-of-year format and UTC time zone. Automatic correction for DST should be disabled. It is very important that the year be set correctly in the DIP-switches; otherwise, the day of year will be incorrect after 28 April of a normal or leap year. As the there are only four dipswitches to set the year and the base value of zero correspondes to 1986, years beyond 2001 recycle with the value of zero corresponding to 2002. The propagation delay DIP-switches should be set according to the distance from the transmitter for both WWV and WWVH, as described in the instructions. While the delay can be set only to within 11 ms, the fudge time1 parameter can be used for vernier corrections.</p> +<p>Using the poll sequence <tt>QTQDQM</tt>, the response timecode is in three sections totalling 50 ASCII printing characters, as concatenated by the driver, in the following format:</p> +<pre> ahh:mm:ss.fffs<cr> yy/dd/mm/ddd<cr> frdzycchhSSFTttttuuxx<cr> @@ -45,32 +46,31 @@ T = transmitter (C = WWV, H = WWVH) tttt = time since last update (0000 = minutes) uu = flush character (03 = ^c) xx = 94 (unknown)</pre> - <p>The alarm condition is indicated by other than <tt>8</tt> at <tt>a</tt>, which occurs during initial synchronization and when received signal is lost for an extended period; unlock condition is indicated by other than <tt>0000</tt> in the <tt>tttt</tt> subfield.</p> - <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>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> - <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 +<p>The alarm condition is indicated by other than <tt>8</tt> at <tt>a</tt>, which occurs during initial synchronization and when received signal is lost for an extended period; unlock condition is indicated by other than <tt>0000</tt> in the <tt>tttt</tt> subfield.</p> +<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>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> +<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> diff --git a/html/drivers/driver30.html b/html/drivers/driver30.html index d29dbcfc2919..ddf9b948882b 100644 --- a/html/drivers/driver30.html +++ b/html/drivers/driver30.html @@ -11,6 +11,9 @@ <body> <h3>Motorola Oncore GPS receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.30.<i>u</i><br> @@ -80,4 +83,4 @@ <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/driver31.html b/html/drivers/driver31.html index aff093c52e33..a329faf849aa 100644 --- a/html/drivers/driver31.html +++ b/html/drivers/driver31.html @@ -11,6 +11,9 @@ <body> <h3>Rockwell Jupiter GPS receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.31.<i>u</i><br> @@ -55,4 +58,4 @@ </html> -=
\ No newline at end of file += diff --git a/html/drivers/driver32.html b/html/drivers/driver32.html index 947924841468..8cb810a6029c 100644 --- a/html/drivers/driver32.html +++ b/html/drivers/driver32.html @@ -10,6 +10,9 @@ <body> <h3>Chrono-log K-series WWVB receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.32.<i>u</i><br> @@ -30,9 +33,8 @@ L - \n (newline) Z - timestamp indicator hh:mm:ss - local time </pre> - <!-- hhmts start -->Last modified: Sun Feb 14 11:57:27 EST 1999 <!-- hhmts end --> <hr> <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/driver33.html b/html/drivers/driver33.html index f50dfb63239c..6142f53077a7 100644 --- a/html/drivers/driver33.html +++ b/html/drivers/driver33.html @@ -10,6 +10,9 @@ <body> <h3>Dumb Clock</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.33.<i>u</i><br> @@ -27,9 +30,7 @@ C - \r (carriage return) L - \n (newline) </pre> <hr> - <!-- hhmts start -->Last modified: Sun Feb 14 12:07:01 EST 1999 <!-- hhmts end --> - <hr> <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/driver34.html b/html/drivers/driver34.html index a742d42a24d3..65ce81948997 100644 --- a/html/drivers/driver34.html +++ b/html/drivers/driver34.html @@ -10,6 +10,9 @@ <body> <h3>Ultralink Clock</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->31-Dec-2007 19:43<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.34.<i>u</i><br> diff --git a/html/drivers/driver35.html b/html/drivers/driver35.html index 78a0881fcd46..3ded63febc26 100644 --- a/html/drivers/driver35.html +++ b/html/drivers/driver35.html @@ -10,6 +10,9 @@ <body> <h3>Conrad parallel port radio clock</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.35.<i>u</i><br> @@ -45,4 +48,4 @@ <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/driver36.html b/html/drivers/driver36.html index e96f73048cfb..2b253245cccb 100644 --- a/html/drivers/driver36.html +++ b/html/drivers/driver36.html @@ -1,147 +1,150 @@ <!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>Radio WWV/H Audio Demodulator/Decoder</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Radio WWV/H Audio Demodulator/Decoder</h3> - <hr> - <h4>Synopsis</h4> - Address: 127.127.36.<i>u</i><br> - Reference ID: <tt>WV<i>f</i></tt> or <tt>WH<i>f</i></tt><br> - 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 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> - <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> - <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 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>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 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 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> 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>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 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. - <dt><tt>q</tt> - <dd>The quality character is a four-bit hexadecimal code showing which alarms have been raised. Each bit is associated with a specific alarm condition according to the following: - <dl> - <dt><tt>0x8</tt> - <dd>synch alarm. The decoder is not synchronized to the station within 125 <font face="Symbol">m</font>s. - <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 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>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. - <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 station identifier shows the station, <tt>WV<i>f</i></tt> for WWV or <tt>WH<i>f</i></tt> for WWVH, and frequency <i><tt>f</tt></i> being tracked. If neither station is heard on any frequency, the reference identifier shows <tt>NONE</tt>. - <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 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>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> - <p><tt>0 2000 006 22:36:00 S +3 1 115 WV20 86 5 66.4 1024</tt></p> - <p>Here the clock has been set and no alarms are raised. The year, day and time are displayed along with no leap warning, standard time and DUT +0.3 s. The clock was set on the last minute, the AGC is safely in the middle ot the range 0-255, and the receiver is tracking WWV on 20 MHz. Good receiving conditions prevail, as indicated by the metric 86 and 5 bit errors during the last minute. The current frequency is 66.4 PPM and the averaging interval is 1024 s, indicating the maximum precision available.</p> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the propagation delay for WWV (40:40:49.0N 105:02:27.0W), in seconds and fraction, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>Specifies the propagation delay for WWVH (21:59:26.0N 159:46:00.0W), 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>Ordinarily, this field specifies the driver reference identifier; however, the driver sets the reference identifier automatically as described above. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Specifies the microphone port if set to zero or the line-in port if set to one. It does not seem useful to specify the compact disc player port. - <dt><tt>flag3 0 | 1</tt> - <dd>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> - </body> - -</html>
\ No newline at end of file +<head> +<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> +<meta name="generator" content="HTML Tidy, see www.w3.org"> +<title>Radio WWV/H Audio Demodulator/Decoder</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>Radio WWV/H Audio Demodulator/Decoder</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> +Last updage: + <!-- #BeginDate format:En2m -->15-Nov-2012 06:42<!-- #EndDate --> +UTC</p> +<hr> +<h4>Synopsis</h4> +Address: 127.127.36.<i>u</i><br> +Reference ID: <tt>WV<i>f</i></tt> or <tt>WH<i>f</i></tt><br> +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 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 μ-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> +<h4>Technical Overview</h4> +<p>The driver processes 8-kHz μ-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> +<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 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>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 μ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 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 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> 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>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 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></dt> + <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 μs.</dd> + <dt><tt>q</tt></dt> + <dd>The quality character is a four-bit hexadecimal code showing which alarms have been raised. Each bit is associated with a specific alarm condition according to the following: + <dl> + <dt><tt>0x8</tt></dt> + <dd>synch alarm. The decoder is not synchronized to the station within 125 μs.</dd> + <dt><tt>0x4</tt></dt> + <dd>Digit error alarm. Less than nine decimal digits were found in the last minute.</dd> + <dt><tt>0x2</tt></dt> + <dd>Error alarm. More than 40 data bit errors were found in the last minute.</dd> + <dt><tt>0x1</tt></dt> + <dd>Compare alarm. A maximum-likelihood digit failed to agree with the current associated clock digit in the last minute.</dd> + </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.</dd> + <dt><tt>yyyy ddd hh:mm:ss</tt></dt> + <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.</dd> + <dt><tt>l</tt></dt> + <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.</dd> + <dt><tt>d</tt></dt> + <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.</dd> + <dt><tt>du</tt></dt> + <dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.</dd> + <dt><tt>lset</tt></dt> + <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 μs.</dd> + <dt><tt>agc</tt></dt> + <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.</dd> + <dt><tt>ident</tt></dt> + <dd>The station identifier shows the station, <tt>WV<i>f</i></tt> for WWV or <tt>WH<i>f</i></tt> for WWVH, and frequency <i><tt>f</tt></i> being tracked. If neither station is heard on any frequency, the reference identifier shows <tt>NONE</tt>.</dd> + <dt><tt>metric</tt></dt> + <dd>The signal metric described above from 0 (no signal) to 100 (best).</dd> + <dt><tt>errs</tt></dt> + <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.</dd> + <dt><tt>freq</tt></dt> + <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.</dd> + <dt><tt>avg</tt></dt> + <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.</dd> +</dl> +<p>An example timecode is:</p> +<p><tt>0 2000 006 22:36:00 S +3 1 115 WV20 86 5 66.4 1024</tt></p> +<p>Here the clock has been set and no alarms are raised. The year, day and time are displayed along with no leap warning, standard time and DUT +0.3 s. The clock was set on the last minute, the AGC is safely in the middle ot the range 0-255, and the receiver is tracking WWV on 20 MHz. Good receiving conditions prevail, as indicated by the metric 86 and 5 bit errors during the last minute. The current frequency is 66.4 PPM and the averaging interval is 1024 s, indicating the maximum precision available.</p> +<h4>Fudge Factors</h4> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the propagation delay for WWV (40:40:49.0N 105:02:27.0W), in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Specifies the propagation delay for WWVH (21:59:26.0N 159:46:00.0W), in seconds and fraction, with default 0.0.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Ordinarily, this field specifies the driver reference identifier; however, the driver sets the reference identifier automatically as described above.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Specifies the microphone port if set to zero or the line-in port if set to one. It does not seem useful to specify the compact disc player port.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> +</dl> +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +</body> +</html> diff --git a/html/drivers/driver37.html b/html/drivers/driver37.html index 3bd50857dcc3..c87a82f1e90f 100644 --- a/html/drivers/driver37.html +++ b/html/drivers/driver37.html @@ -10,6 +10,9 @@ <body> <h3>Forum Graphic GPS Dating station</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> <p>Address: 127.127.37.<i>u</i><br> @@ -48,4 +51,4 @@ <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/driver38.html b/html/drivers/driver38.html index 283e38f24834..445d70df2975 100644 --- a/html/drivers/driver38.html +++ b/html/drivers/driver38.html @@ -10,6 +10,9 @@ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> <h1><font face="Arial"><i><blink><font size="5">hopf</font></blink></i><font size="+2"> </font><font size="3">Serial Line Receivers (6021 and kompatible)</font></font></h1> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h2><font size="+1">Synopsis</font></h2> <table width="100%"> @@ -110,7 +113,7 @@ <hr> <h2><font size="+1">Fudge Factors</font></h2> <dl> - <dt><b><a name="time1"></a><tt><font size="+1"><a href="#Configuration">time1 <i>time</i></a></font></tt></b> + <dt><b><tt><font size="+1">time1 <i>time</i></font></tt></b> <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0. Should be set to 20 milliseconds to correct serial line and operating system delays incurred in capturing time stamps from the synchronous packets. <dt><tt><font size="+1"><a href="#REFID"><b>refid <i>string</i></b></a></font></tt> <dd>Specifies the driver reference identifier, <b>GPS </b><i>or</i> <b>DCF</b>. @@ -123,9 +126,8 @@ <hr> <h3>Questions or Comments:</h3> <p><a href="mailto:altmeier@atlsoft.de">Bernd Altmeier</a><a href="http://www.ATLSoft.de"><br>Ing.-Büro für Software www.ATLSoft.de</a></p> - <p>(last updated 02/28/2001)<br> </p> <hr> <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/driver39.html b/html/drivers/driver39.html index 482134e0efd8..9e1605f8141b 100644 --- a/html/drivers/driver39.html +++ b/html/drivers/driver39.html @@ -10,6 +10,9 @@ <body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> <h1><font face="Arial"><i><blink><font size="5">hopf</font></blink></i><font size="+2"> </font><font size="3">PCI-Bus Receiver (6039 GPS/DCF77)</font></font></h1> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <div align="center"> <center> @@ -105,9 +108,8 @@ <hr> <h3>Questions or Comments:</h3> <p><a href="mailto:altmeier@atlsoft.de">Bernd Altmeier</a><a href="http://www.ATLSoft.de"><br>Ing.-Büro für Software www.ATLSoft.de</a></p> - <p>(last updated 03/02/2001)<br> </p> <hr> <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/driver4.html b/html/drivers/driver4.html index 788bc46efdca..213928940add 100644 --- a/html/drivers/driver4.html +++ b/html/drivers/driver4.html @@ -1,108 +1,76 @@ <!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>Spectracom WWVB/GPS Receivers</title> <link href="scripts/style.css" type="text/css" rel="stylesheet"> <style type="text/css"> <!-- -.style1 {font-family: Symbol} +.style1 { + font-family: Symbol +} --> </style> </head> - <body> - <h3>Spectracom WWVB/GPS Receivers</h3> - +<p>Author: David L. Mills (mills@udel.edu)<br> + Last update: + <!-- #BeginDate format:En2m -->11-Sep-2010 05:56<!-- #EndDate --> + UTC</p> <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> - + 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> - + <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> - + 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> - + 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> - + 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> - +<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. - + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Specifies the serial time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>WWVB</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the falling edge if 1.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel discipline if 1.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> </dl> - <hr> <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/driver40.html b/html/drivers/driver40.html index 1901dcdbff74..6799f7699611 100644 --- a/html/drivers/driver40.html +++ b/html/drivers/driver40.html @@ -14,25 +14,40 @@ <body> <h3>JJY Receivers</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->3-May-2011 00:20<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> Address: 127.127.40.<em>u</em><br> Reference ID: <code>JJY</code><br> Driver ID: <code>JJY</code><br> - Serial Port: <code>/dev/jjy<em>u</em></code>; 9600|4800(See corresponding receiver) baud, 8-bits, no parity, 1 stop bit + Serial Port: <code>/dev/jjy<em>u</em></code>; See corresponding receiver <h4>Description</h4> <p>This driver supports the following JJY receivers sold in Japan.</p> <ul> - <li>Tristate Ltd. JJY01 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)<br> + + <li> + <p>Tristate Ltd. JJY01, JJY02 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)</p><br> <dl> <dt>NTP configuration ( ntp.conf )</dt> <dd> <p>server 127.127.40.X mode 1</p> + <dl> + <dt>fudge 127.127.40.X flag1 0|1</dt> + <dd> + <p>Flag1 has no effect for time synchronization. When a flag1 is set to 1, status commands are issued before DATE and STIM commands, and write a response text into a clockstats file.</p> + <table border="1" summary="fudge flag1"> + <tr><td>0 (Default)</td><td>DCST and STUS commands are not issued</td></tr> + <tr><td>1</td><td>DCST and STUS commands are issued</td></tr> + </table> + </dd> + </dl> <br> </dd> - <dt>RS-232C</dt> + <dt>Interface</dt> <dd> - <p>9600 Baud</p> + <p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p> <br> </dd> <dt>Time code format</dt> @@ -44,29 +59,32 @@ <td>Reply</td> </tr> <tr> - <td><code>date<CR><LF></code></td> + <td><code>date{CR}{LF}</code></td> <td> --> </td> - <td><code>YYYY/MM/DD WWW<CR><LF></code></td> + <td><code>YYYY/MM/DD WWW{CR}{LF}</code></td> </tr> <tr> - <td><code>stim<CR><LF></code></td> + <td><code>stim{CR}{LF}</code></td> <td> --> </td> - <td><code>HH:MM:SS<CR><LF></code></td> + <td><code>HH:MM:SS{CR}{LF}</code></td> </tr> </table> <br> </dd> </dl> - <li>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)<br> + </li> + + <li> + <p>C-DEX Co.,Ltd. JST2000 <a href="http://www.c-dex.co.jp/">http://www.c-dex.co.jp/</a> (Japanese only)</p><br> <dl> <dt>NTP configuration ( ntp.conf )</dt> <dd> <p>server 127.127.40.X mode 2</p> <br> </dd> - <dt>RS-232C</dt> + <dt>Interface</dt> <dd> - <p>9600 Baud</p> + <p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p> <br> </dd> <dt>Time code format</dt> @@ -78,25 +96,27 @@ <td>Reply</td> </tr> <tr> - <td><code><ENQ>1J<ETX></code></td> + <td><code>{ENQ}1J{ETX}</code></td> <td> --> </td> - <td><code><STX>JYYMMDD HHMMSSS<ETX></code></td> + <td><code>{STX}JYYMMDD HHMMSSS{ETX}</code></td> </tr> </table> <br> </dd> </dl> + </li> + <li> - <p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p> + <p>Echo Keisokuki Co.,Ltd. LT-2000 <a href="http://www.clock.co.jp/">http://www.clock.co.jp/</a> (Japanese only)</p><br> <dl> <dt>NTP configuration ( ntp.conf )</dt> <dd> <p>server 127.127.40.X mode 3</p> <br> </dd> - <dt>RS-232C</dt> + <dt>Interface</dt> <dd> - <p>9600 Baud</p> + <p>RS-232C, 9600 baud, 8-bits, no parity, 1 stop bit</p> <br> </dd> <dt>Time code format</dt> @@ -115,7 +135,7 @@ <tr> <td>( Every second before 0.5 second )</td> <td></td> - <td><code>YYMMDDWHHMMSS<ST1><ST2><ST3><ST4><CR></code></td> + <td><code>YYMMDDWHHMMSS{ST1}{ST2}{ST3}{ST4}{CR}</code></td> </tr> <tr> <td><code>#</code></td> @@ -126,17 +146,19 @@ <br> </dd> </dl> + </li> + <li> - <p>CITIZEN T.I.C. CO.,LTD. JJY-200 <a href="http://www.tic-citizen.co.jp/">http://www.tic-citizen.co.jp/</a> (Japanese only)</p> + <p>CITIZEN T.I.C. CO.,LTD. JJY-200 <a href="http://www.tic-citizen.co.jp/">http://www.tic-citizen.co.jp/</a> (Japanese only)</p><br> <dl> <dt>NTP configuration ( ntp.conf )</dt> <dd> <p>server 127.127.40.X mode 4</p> <br> </dd> - <dt>RS-232C</dt> + <dt>Interface</dt> <dd> - <p>4800 Baud</p> + <p>RS-232C, 4800 baud, 8-bits, no parity, 1 stop bit</p> <br> </dd> <dt>Time code format</dt> @@ -150,16 +172,69 @@ <tr> <td>( Every second )</td> <td></td> - <td><code>'XX YY/MM/DD W HH:MM:SS<CR></code></td> + <td><code>'XX YY/MM/DD W HH:MM:SS{CR}</code></td> + </tr> + </table> + <br> + </dd> + </dl> + </li> + + <li> + <p>Tristate Ltd. TS-GPSclock-01 <a href="http://www.tristate.ne.jp/">http://www.tristate.ne.jp/</a> (Japanese only)</p> + <p>This driver supports the Tristate TS-GPSclock-01 in command/response mode, though it is a GPS clock, not JJY radio clock. Using the menus and the onboard switches, the TS-GPSclock-01 should be set to command/response mode and JST time zone.<br> + Besides this driver ( Type 40 ), <a href="driver20.html">the generic NMEA GPS driver ( Type 20 )</a> supports the TS-GPSclock-01 in NMEA mode.</p> + <dl> + <dt>NTP configuration ( ntp.conf )</dt> + <dd> + <p>server 127.127.40.X mode 5</p> + <dl> + <dt>fudge 127.127.40.X flag1 0|1</dt> + <dd> + <p>Flag1 has no effect for time synchronization. When a flag1 is set to 1, status command is issued before DATE and TIME commands, and write a response text into a clockstats file.</p> + <table border="1" summary="fudge flag1"> + <tr><td>0 (Default)</td><td>STUS command is not issued</td></tr> + <tr><td>1</td><td>STUS command is issued</td></tr> + </table> + </dd> + </dl> + <br> + </dd> + <dt>Interface</dt> + <dd> + <p>USB ( /dev/ttyACM<em>0</em> )</p> + <br> + </dd> + <dt>Time code format</dt> + <dd><br> + <table summary="CommandAndReply"> + <tr> + <td>Command</td> + <td> --> </td> + <td>Reply</td> + </tr> + <tr> + <td><code>date{CR}{LF}</code></td> + <td> --> </td> + <td><code>YYYY/MM/DD{CR}{LF}</code></td> + </tr> + <tr> + <td><code>time{CR}{LF}</code></td> + <td> --> </td> + <td><code>HH:MM:SS{CR}{LF}</code></td> </tr> </table> <br> </dd> </dl> + </li> + </ul> <p>JJY is the radio station which transmites the JST (Japan Standard Time) in long wave radio. The station JJY is operated by the National Institute of Information and Communications Technology. An operating announcement and some information are avaiable from <a href="http://www.nict.go.jp/">http://www.nict.go.jp/</a> (English and Japanese) and <a href="http://jjy.nict.go.jp/">http://jjy.nict.go.jp/</a> (English and Japanese)</p> - <p>The user is expected to provide a symbolic link to an available serial port device. This is typically performed by a command such as:</p> + <p>The user is expected to provide a symbolic link to an available serial port device. This is typically performed by a command such as;</p> <p><code>ln -s /dev/ttyS0 /dev/jjy0</code></p> + <p>Using RS232C to USB converter cable, the clock can be connected to an USB port instead of a serial port. In this case, typical symbolic link command is as follows; + <p><code>ln -s /dev/ttyUSB0 /dev/jjy0</code></p> <p>Windows NT does not support symbolic links to device files. COM<em>X</em>: is the unit used by the driver, based on the refclock unit number, where unit 1 corresponds to COM1: and unit 3 corresponds to COM3:</p> <h4>Monitor Data</h4> <p>The driver writes each timecode as received to the <code>clockstats</code> file.</p> @@ -174,7 +249,7 @@ <dt><code>refid <em>string</em></code> <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <code>JJY</code>. <dt><code>flag1 0 | 1</code> - <dd>Not used by this driver. + <dd>See corresponding receiver. <dt><code>flag2 0 | 1</code> <dd>Not used by this driver. <dt><code>flag3 0 | 1</code> diff --git a/html/drivers/driver42.html b/html/drivers/driver42.html index 70820508ea88..86f676e3e1fb 100644 --- a/html/drivers/driver42.html +++ b/html/drivers/driver42.html @@ -10,6 +10,9 @@ <body> <h3>Zyfer GPStarplus Receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> Address: 127.127.42.<i>u</i><br> @@ -27,4 +30,4 @@ <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/driver43.html b/html/drivers/driver43.html index 0e1553fce832..6d04102dd81f 100644 --- a/html/drivers/driver43.html +++ b/html/drivers/driver43.html @@ -10,6 +10,9 @@ <body> <h3>RIPE NCC interface for Trimble Palisade</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <img src="../pic/driver43_2.jpg" alt="Trimble Acutime 2000" align="right"> <h4>Synopsis</h4> @@ -62,4 +65,4 @@ S1 [prn] [channel] [aqflag] [ephstat] [snr] [azinuth] [elevation] <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/driver44.html b/html/drivers/driver44.html index d2cddb9c7d18..a3fac5c5a9e0 100755 --- a/html/drivers/driver44.html +++ b/html/drivers/driver44.html @@ -11,6 +11,9 @@ <body> <h1>NeoClock4X - DCF77 / TDF serial line receiver<br> </h1> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr size="2" width="100%"> <h2>Synopsis</h2> <table width="100%"> @@ -85,4 +88,4 @@ <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/driver45.html b/html/drivers/driver45.html new file mode 100644 index 000000000000..bef883fe87b3 --- /dev/null +++ b/html/drivers/driver45.html @@ -0,0 +1,32 @@ +<!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>Spectracom TSYNC PCI</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> + + <body> + <h3>Spectracom TSYNC PCI</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->26-Mar-2012 05:10<!-- #EndDate --> + UTC</p> + <hr> + <h4>Synopsis</h4> + Address: 127.127.45.<i>u</i><br> + Reference ID: one of <tt>GPS</tt>, <tt>IRIG</tt>, <tt>HVQ</tt>, <tt>FREQ</tt>, <tt>ACTS</tt>, <tt>PPS</tt>, <tt>PTP</tt>, <tt>ACT</tt>, <tt>USR</tt>, <tt>LOCL</tt><br> + Driver ID: <tt>Spectracom TSYNC PCI</tt><br> + Driver Port: <tt>/dev/tsyncpci<i>u</i></tt> + Features: <tt>(none)</tt> + <h4>Description</h4> + <p>This driver supports the <a + href="http://www.spectracomcorp.com/ProductsServices/TimingSynchronization/BuslevelTiming">Spectracom TSYNC PCI</a> receiver.</p> + <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> diff --git a/html/drivers/driver46.html b/html/drivers/driver46.html new file mode 100644 index 000000000000..40aded80cca1 --- /dev/null +++ b/html/drivers/driver46.html @@ -0,0 +1,184 @@ +<!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>GPSD-NG client driver</title> + + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + <style type="text/css"> + table.dlstable { font-size:85%; } + td.ttf{ font-family:Courier; font-weight:bold; } + </style></head> + + + + <body> + <h3>GPSD NG client driver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->1-Mar-2014 03:48<!-- #EndDate --> + UTC</p> + <hr> + <h4>Synopsis</h4> + + <p> + Address: 127.127.46.<i>u</i><br> + Reference ID: <tt>GPSD</tt><br> + Driver ID: <tt>GPSD_JSON</tt><br> + Serial Port: <tt>/dev/gps<i>u</i></tt> as symlink to the true + device (not used directly; see below)<br> + Features: <tt></tt> + </p> + + <h4>Description</h4> + + <p> + This driver is a client driver to the <i>GPSD</i> daemon, which + over the time became increasingly popular for UN*Xish + platforms. <i>GPSD</i> can manage several devices in parallel, + aggregate information, and acts as a data hub for client + applications. <i>GPSD</i> can also auto-detect and handle PPS + hardware signals on serial ports. Have a look + at <a href="http://www.catb.org/gpsd/">the + <i>GPSD</i> project page</a>. + </p> + <p> + <b>It is important to understand that this driver works best + using a GPS device with PPS support.</b> + </p> + <p> + The GPSD-NG protocol is text based, using JSON notation to + transfer records in form of JSON objects. The driver uses a + TCP/IP connection to <tt>localhost:gpsd</tt> to connect to the + daemon and then requests the GPS + device <tt>/dev/gps<i>u</i></tt> to be watched. (Different clock + units use different devices, and + <i>GPSD</i> is able to give only the relevant information to a clock + instance.) + </p> + <p> + This driver does not expect <i>GPSD</i> to be running or the + clock device to be present <i>a priori</i>; it will try to + re-establish a lost or hitherto unsuccessful connection and will + wait for device to come up in <i>GPSD.</i> There is an initial + 10 seconds delay between a connection loss or failed attempt and + the next reconnect attempt; this makes sure that there is no + thrashing on the network layer. If the connection fails again, + an exponential back off is used with an upper limit of + approximately 10 minutes. + </p> + <p> + The overall accuracy depends on the receiver used. The driver + uses the error estimations (95% probability limits) provided by + <i>GPSD</i> to set the clock precision dynamically according to these + readings. + </p> + <p> + The driver needs the VERSION, TPV, PPS and WATCH objects of + the <i>GPSD</i> protocol. (Others are quietly ignored.) + </p> + + + <h4>Naming a Device</h4> + <p> + The <i>GPSD</i> driver uses the same name as the NMEA driver, + namely <tt>/dev/gps<i>u</i></tt>. There is a simple reason for + that: While the NMEA driver and the <i>GPSD</i> driver can be + active at the same time <b>for different devices</b>, + they cannot access the same device at a time. Having the same + name helps on that. It also eases migration from using NMEA + directly to using <i>GPSD</i>, as no new links etc need to be + created. + </p> + <p> + <i>GPSD</i> is normally started with the device name to access; + it can also be instructed by hot-plug scripts to add or remove + devices from its device pool. Luckily, the symlinks used by the + NMEA driver are happily accepted and used by <i>GPSD</i>; this + makes it possible to use the symlink names as device + identification. This makes the migration from the built-in NMEA + driver a bit easier. + </p> + <p><b>Note:</b> <i>GPSD</i> (as of version 3.10) cannot + use kernel mode PPS on devices that are hot-plugged. This would + require to attach the PPS line discipline to the file, which is + not possible when running with root privileges dropped. This is + not likely to change in the future. + </p> + + <h4>The 'mode' byte</h4> + <p> + A few operation modes can be selected with the mode word. + </p> + <p> + <table border="1" frame="box" rules="all"> + <th colspan="3">The Mode Word</th> + <tr> <td>Bits</td><td>Value</td><td>Description</td> + </tr> + <tr> <td rowspan="4"align="center">0..1</td><td align="center">0</td> + <td>Uses TPV to get absolute time stamps for full + synchronization. If PPS is available , it is used to improve + the precision, but the clock can work without it.</td> + </tr> + <tr><td align="center">1</td> + <td>Require TPV <b>and</b> PPS to work.</td> + </tr> + <tr><td align="center">2</td> + <td>Ignore PPS data, run on TPV only. This is not a + recommended mode unless the serial timing is very stable + and GPSD provides an information element in TPV that + indicates the receive time of the fix data.</td> + </tr> + <tr><td align="center">3</td> + <td>PPS-only mode. Ignores TPV and does only the PPS phase + correction. This means that some other source must get NTPD + close to synchronisation; only after that happened and the + phase shift between the system clock and the PPS pulse is + less than 125msec the PPS lock will be engaged.</td> + </tr> + <tf colspan="3"><b>IMPORTANT: work in progress, mode + word ignored right now. Fixed mode '0' operation.</b></tf> + </table> + </p> + + <h4>Syslog flood throttle</h4> + <p>This driver can create a lot of syslog messages when things go + wrong, and cluttering the log files is frowned upon. So we attempt + to log persistent or recurring errors only once per hour. On the + other hand, when tracking a problem the syslog flood throttle can + get into the way.</p> + <p>Therefore, fudge <i>flag3</i> can be used to <i>disable</i> the + flood throttle at any time; the throttle is engaged by + default. Running with the syslog flood throttle disabled for + lengthy time is not recommended unless the log files are closely + monitored.</p> + + <h4>Fudge Factors</h4> + + <dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the PPS time offset calibration factor, in seconds + and fraction, with default 0.0.</dd> + <dt><a name="fudgetime2"><tt>time2 <i>time</i></tt></a></dt> + <dd>Specifies the TPV time offset calibration factor, in seconds + and fraction, with default 0.0.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string + from one to four characters, with default <tt>GPSD</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt><dd><i>(not used)</i></dd> + <dt><tt>flag2 0 | 1</tt></dt><dd><i>(not used)</i></dd> + <dt><tt>flag3 0 | 1</tt></dt><dd>If set, <i>disable</i> the + log throttle. Useful when tracking problems in the interaction + between <i>GPSD</i> and <i>NTPD</i>, since now all error + events are logged. Persistent/recurrent errors can easily fill + up the log, so this should only be enabled during bug + hunts.</dd> + <dt><tt>flag4 0 | 1</tt></dt><dd>If set, write a clock stats + line on every poll cycle.</dd> + </dl> + + <p>Additional Information</p> + <p><a href="../refclock.html">Reference Clock Drivers</a></p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body></html> diff --git a/html/drivers/driver5.html b/html/drivers/driver5.html index 1b539acaa2de..fa19764fac3e 100644 --- a/html/drivers/driver5.html +++ b/html/drivers/driver5.html @@ -2,71 +2,82 @@ <html> - <head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <title>TrueTime GPS/GOES/OMEGA 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"> + <title>TrueTime GPS/GOES/OMEGA/WWV Receivers</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> - <body> - <h3>TrueTime GPS/GOES/OMEGA Receivers</h3> - <hr> - <h4>Synopsis</h4> - Address: 127.127.5.<i>u</i><br> - Reference ID: <tt>GPS, OMEGA, GOES</tt><br> - Driver ID: <tt>TRUETIME</tt><br> - Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> - Features: <tt>tty_clk</tt> - <h4>Description</h4> - <p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.</p> - <p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p> - <p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt> A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of</p> - <dl> - <dt>468-DC GOES Receiver<br> - GPS-TM/TMD Receiver - <dd>? +/- 500 milliseconds # +/- 50 milliseconds<br> - * +/- 5 milliseconds . +/- 1 millisecond<br> - space less than 1 millisecond - <dt>OM-DC OMEGA Receiver: - <dd>> +/- 5 seconds<br> - ? +/- 500 milliseconds # +/- 50 milliseconds<br> - * +/- 5 milliseconds . +/- 1 millisecond<br> - A-H less than 1 millisecond. Character indicates which station is being received as follows<br> - A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br> - The carriage return start bit begins on 0 seconds and extends to 1 bit time. - </dl> - <h4>Notes on 468-DC and OMEGA receiver:</h4> - <p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p> - <h4>Notes on the 468-DC receiver:</h4> - <p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p> - <p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p> - <p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p> - <p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p> - <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, to be used for the West satellite, with default 0.0. - <dt><tt>time2 <i>time</i></tt> - <dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, 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>TRUE</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Silence the clock side of ntpd, just reading the clock without trying to write to it. - <dt><tt>flag2 0 | 1</tt> - <dd>Generate a debug file /tmp/true%d. - <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>TrueTime GPS/GOES/OMEGA/WWV Receivers</h3> + <hr> + <h4>Synopsis</h4> + Address: 127.127.5.<i>u</i><br> + Reference ID: <tt>GPS, OMEGA, GOES, WWV</tt><br> + Driver ID: <tt>TRUETIME</tt><br> + Serial Port: <tt>/dev/true<i>u</i></tt>; 9600 baud, 8-bits, no parity<br> + Features: <tt>tty_clk</tt> + <h4>Description</h4> + <p>This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, the TL-3 WWV receiver, and very likely others in the same model families that use the same timecode formats.</p> + <p>Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.</p> + <p>Timcode format: <tt>ADDD:HH:MM:SSQCL</tt><br> +A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed</p><br> +Quality codes indicate possible error of: + <dl> + <dt>468-DC GOES Receiver<br> + GPS-TM/TMD Receiver + <dd>? +/- 500 milliseconds # +/- 50 milliseconds<br> + * +/- 5 milliseconds . +/- 1 millisecond<br> + space less than 1 millisecond + <dt>OM-DC OMEGA Receiver: + <dd>> +/- 5 seconds<br> + ? +/- 500 milliseconds # +/- 50 milliseconds<br> + * +/- 5 milliseconds . +/- 1 millisecond<br> + A-H less than 1 millisecond. Character indicates which station is being received as follows<br> + A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan<br> + The carriage return start bit begins on 0 seconds and extends to 1 bit time. + <dt>TL-3 WWV Receiver: + <dd>? receiver is unlocked<br> + <dd>space +/- 5 milliseconds<br> + </dl> + <h4>Notes on 468-DC and OMEGA receiver:</h4> + <p>Send the clock a <tt>R</tt> or <tt>C</tt> and once per second a timestamp will appear. Send a <tt>R</tt> to get the satellite position once (GOES only).</p> + <h4>Notes on the 468-DC receiver:</h4> + <p>Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line</p> + <p><tt>fudge 127.127.5.0 time1 +0.008 time2 -0.004</tt></p> + <p>This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.</p> + <p>The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)</p> + <h4>Notes on the TL-3 receiver:</h4> + <p>The mini-DIN RS-232 port uses the Apple pinout.<br> + Send the clock ST1 to turn on continuous (1/sec) timecodes. +You can also enable "mode C" via the front panel. ST0 turns off this mode.<br> +QV will return the firmware revision (and is useful in identifying this clock.)<br> +QW will return its weekly signal log, useful if you're testing antennas. You may wish to turn the loss interval down from 4h (04) to 1h (01), so the receiver declares itself unlocked sooner. When in holdover, drift can be on the order of 10 ms/hr since there is no high quality reference oscillator.</p> + <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, to be used for the West satellite, with default 0.0. + <dt><tt>time2 <i>time</i></tt> + <dd>. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, 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>TRUE</tt>. + <dt><tt>flag1 0 | 1</tt> + <dd>Silence the clock side of ntpd, just reading the clock without trying to write to it. + <dt><tt>flag2 0 | 1</tt> + <dd>Generate a debug file /tmp/true%d. + <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 +</html> diff --git a/html/drivers/driver6.html b/html/drivers/driver6.html index eb12bdd39f99..ebb3683a9a02 100644 --- a/html/drivers/driver6.html +++ b/html/drivers/driver6.html @@ -1,76 +1,80 @@ <!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> - <h4>Description</h4> - <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> - <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. 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> - <dd>Low signal. The carrier amplitude is less than 100 units. This is usually the result of no signal or wrong input port. - <dt><tt>x02</tt> - <dd>Frequency error. The codec frequency error is greater than 250 PPM. This may be due to wrong signal format or (rarely) defective codec. - <dt><tt>x04</tt> - <dd>Modulation error. The IRIG modulation index is less than 0.5. This is usually the result of an overdriven codec, wrong signal format or wrong input port. - <dt><tt>x08</tt> - <dd>Frame synch error. The decoder frame does not match the IRIG frame. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. It may also be the result of an IRIG signature check which indicates a failure of the IRIG signal synchronization source. - <dt><tt>x10</tt> - <dd>Data bit error. The data bit length is out of tolerance. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. - <dt><tt>x20</tt> - <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> - <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>IRIG</tt>. - <dt><tt>flag1 0 | 1</tt> - <dd>Not used by this driver. - <dt><tt>flag2 0 | 1</tt> - <dd>Specifies the microphone port if set to zero or the line-in port if set to one. It does not seem useful to specify the compact disc player port. - <dt><tt>flag3 0 | 1</tt> - <dd>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> - </body> -</html>
\ No newline at end of file +<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> +<p>Author: David L. Mills (mills@udel.edu)<br> +Last update: + <!-- #BeginDate format:En2m -->17-Jul-2014 02:17<!-- #EndDate --> + UTC</p> +<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> +<h4>Description</h4> +<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 μ-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 μ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 μs with standard deviation 10 μs. Most of this is due to residuals after filtering and averaging the raw codec samples, which have an inherent jitter of 125 μ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> +<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 μ-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. 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></dt> + <dd>Low signal. The carrier amplitude is less than 100 units. This is usually the result of no signal or wrong input port.</dd> + <dt><tt>x02</tt></dt> + <dd>Frequency error. The codec frequency error is greater than 250 PPM. This may be due to wrong signal format or (rarely) defective codec.</dd> + <dt><tt>x04</tt></dt> + <dd>Modulation error. The IRIG modulation index is less than 0.5. This is usually the result of an overdriven codec, wrong signal format or wrong input port.</dd> + <dt><tt>x08</tt></dt> + <dd>Frame synch error. The decoder frame does not match the IRIG frame. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal. It may also be the result of an IRIG signature check which indicates a failure of the IRIG signal synchronization source.</dd> + <dt><tt>x10</tt></dt> + <dd>Data bit error. The data bit length is out of tolerance. This is usually the result of an overdriven codec, wrong signal format or noisy IRIG signal.</dd> + <dt><tt>x20</tt></dt> + <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.</dd> + <dt><tt>x40</tt></dt> + <dd>Codec error (overrun). The machine is not fast enough to keep up with the codec.</dd> + <dt><tt>x80</tt></dt> + <dd>Device status error (Spectracom).</dd> +</dl> +<h4>Fudge Factors</h4> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>IRIG</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <dd>Specifies the microphone port if set to zero or the line-in port if set to one. It does not seem useful to specify the compact disc player port.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <dd>Enables audio monitoring of the input signal. For this purpose, the speaker volume must be set before the driver is started.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> +</dl> +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +</body> +</html> diff --git a/html/drivers/driver7.html b/html/drivers/driver7.html index 6f4874117f2c..90baf61a36be 100644 --- a/html/drivers/driver7.html +++ b/html/drivers/driver7.html @@ -1,65 +1,67 @@ <!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>Radio CHU Audio Demodulator/Decoder</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <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/audio</tt> and <tt>/dev/audioctl</tt> - <h4>Description</h4> - <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> - <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. 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: 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> +<head> +<meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> +<meta name="generator" content="HTML Tidy, see www.w3.org"> +<title>Radio CHU Audio Demodulator/Decoder</title> +<link href="scripts/style.css" type="text/css" rel="stylesheet"> +</head> +<body> +<h3>Radio CHU Audio Demodulator/Decoder</h3> +<p>Author: David L. Mills (mills@udel.edu)<br> +Last update: + <!-- #BeginDate format:En2m -->17-Jul-2014 02:17<!-- #EndDate --> + UTC</p> +<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/audio</tt> and <tt>/dev/audioctl</tt> +<h4>Description</h4> +<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 μ-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> +<h4>Technical Overview</h4> +<p>The driver processes 8-kHz μ-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. 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: 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 yyyy ddd hh:mm:ss lw dst du lset agc rfrq bcnt dist tsmp s sync indicator @@ -78,72 +80,65 @@ 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. - <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 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>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. 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>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. It is encoded as one digit preceeded by sign. - <dt><tt>lset</tt> - <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>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> - </body> - -</html>
\ No newline at end of file +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></dt> + <dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock has been correctly set.</dd> + <dt><tt>q</tt></dt> + <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></dt> + <dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd> + <dt><tt>4</tt></dt> + <dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree.</dd> + <dt><tt>2</tt></dt> + <dd>Format alarm. One or more bursts contained invalid data or was improperly formatted.</dd> + <dt><tt>1</tt></dt> + <dd>Frame alarm. One or more bursts was improperly framed or contained too many repetition errors.</dd> + </dl> + 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.</dd> + <dt><tt>yyyy ddd hh:mm:ss</tt></dt> + <dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.</dd> + <dt><tt>lw</tt></dt> + <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.</dd> + <dt><tt>dst</tt></dt> + <dd>The DST code for Canada encodes the state for all provinces. It is encoded as two hex characters.</dd> + <dt><tt>dut</tt></dt> + <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.</dd> + <dt><tt>lset</tt></dt> + <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.</dd> + <dt><tt>agc</tt></dt> + <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.</dd> + <dt><tt>ident</tt></dt> + <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.</dd> + <dt><tt>dist</tt></dt> + <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.</dd> + <dt><tt>tsmp</tt></dt> + <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.</dd> +</dl> +<h4>Fudge Factors</h4> +<dl> + <dt><tt>time1 <i>time</i></tt></dt> + <dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds and fraction, with default 0.0.</dd> + <dt><tt>time2 <i>time</i></tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>stratum <i>number</i></tt></dt> + <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> + <dt><tt>refid <i>string</i></tt></dt> + <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>CHU</tt>.</dd> + <dt><tt>flag1 0 | 1</tt></dt> + <dd>Not used by this driver.</dd> + <dt><tt>flag2 0 | 1</tt></dt> + <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.</dd> + <dt><tt>flag3 0 | 1</tt></dt> + <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.</dd> + <dt><tt>flag4 0 | 1</tt></dt> + <dd>Enable verbose <tt>clockstats</tt> recording if set.</dd> +</dl> +<hr> +<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> +</body> +</html> diff --git a/html/drivers/driver8.html b/html/drivers/driver8.html index 8e81e5f57f16..ab21f0f1f840 100644 --- a/html/drivers/driver8.html +++ b/html/drivers/driver8.html @@ -2,299 +2,277 @@ <html> - <head> - <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"> - <title>Generic Reference Driver</title> - <link href="scripts/style.css" type="text/css" rel="stylesheet"> - </head> - - <body> - <h3>Generic Reference Driver</h3> - <hr> - <h4>Synopsis</h4> - Address: 127.127.8.<i>u</i><br> - Reference ID: <tt>PARSE</tt><br> - Driver ID: <tt>GENERIC</tt><br> - Serial Port: <tt>/dev/refclock-<i>u</i></tt>; TTY mode according to clock type<br> - PPS device: <tt>/dev/refclockpps-<i>u</i></tt>; alternate PPS device (if not available via the serial port) - <h4>Description</h4> - The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br> - <br> - <p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="#clocklist">list below</a>).</p> - <p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p> - <p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p> - <p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p> - <h4>Timecode variables listed by ntpq (8)</h4> - <p>The ntpq program can read and display several clock variables. These hold the following information:</p> - <dl> - <dt><tt>refclock_format</tt></dt> - <dd>A qualification of the decoded time code format.</dd> - <dt><tt>refclock_states</tt></dt> - <dd>The overall running time and the accumulated times for the clock event states.</dd> - <dt><tt>refclock_status</tt></dt> - <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd> - <dt><tt>refclock_time</tt></dt> - <dd>The local time with the offset to UTC (format HHMM).</dd> - <dt><tt>timecode</tt></dt> - <dd>The actual time code.</dd> - </dl> - <p>If PPS information is present, additional variables are available:</p> - <dl> - <dt><tt>refclock_ppsskew</tt></dt> - <dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd> - <dt><tt>refclock_ppstime</tt></dt> - <dd>The PPS timestamp.</dd> - </dl> - <h4>Supported Devices</h4> - <p>Currently, nineteen clock types (devices /dev/refclock-0 - /dev/refclock-3) are supported by the PARSE driver.<br> - A note on the implementations:</p> - <ul> - <li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel <AT> ntp.org">kardel <AT> ntp.org</a>) are welcome as long as they work within Europe 8-). - <p>Verified implementations are:</p> - <ul> - <li>RAWDCF variants - <p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p> - <li><a href="http://www.meinberg.de">Meinberg clocks</a> - <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p> - </ul> - </ul> - <p>The pictures below have been taken from and are linked to the vendors' web pages.</p> - <a name="clocklist"></a> - <ul> - <li><b><tt>server 127.127.8.0-3 mode 0</tt></b> - <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50μs)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 1</tt></b> - <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50μs)</tt></b><br> - <a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" height="300" width="260" align="top" border="0"></a><br> - <br></p> - - <li><a name="mode2"></a><b><tt>server 127.127.8.0-3 mode 2</tt></b> - <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</tt></b><br> - <a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" height="239" width="330" align="top" border="0"></a><br> - </p> - <p>This mode expects the Meinberg standard time string format with 9600/7E2.</p> - <p><b>Note:</b> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 3</tt></b> - <p><b><tt><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 4</tt></b> - <p><b><tt>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 5</tt></b> - <p><b><tt>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 6</tt></b> - <p><b><tt>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 7</tt></b> - <p><b><tt><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br> - <a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" height="300" width="280" align="top" border="0"></a><br> - </p> - <p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p> - <p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p> - <p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p> - <p><b>Note:</b> mode 7 must not be used with Meinberg PCI cards; use <a href="#mode2">mode 2</a> instead.<br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 8</tt></b> - <p><b><tt><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></tt></b><br> - <a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" height="174" width="200" border="0"></a><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 9</tt></b> - <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / <<1μs)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 10</tt></b> - <p><b><tt><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1μs) (no kernel support yet)</tt></b><br> - <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" height="100" width="420" align="top" border="0"></a><br> - <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" height="100" width="420" border="0"></a><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 11</tt></b> - <p><b><tt>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 12</tt></b> - <p><b><tt><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></tt></b><br> - <a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" height="207" width="238" align="top" border="0"></a><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 13</tt></b> - <p><b><tt>Diem's Computime Radio Clock</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 14</tt></b> - <p><b><tt>RAWDCF receiver (DTR=high/RTS=low)</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 15</tt></b> - <p><b><tt>WHARTON 400A Series Clocks with a 404.2 Serial Interface</tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 16</tt></b> - <p><b><tt>RAWDCF receiver (DTR=low/RTS=high) </tt></b><br> - <br></p> - - <li><b><tt>server 127.127.8.0-3 mode 17</tt></b> - <p><b><tt>VARITEXT Receiver (MSF) </tt></b><br> - <br></p> - - <li><a name="mode18"></a><b><tt>server 127.127.8.0-3 mode 18</tt></b> - <p><b><tt><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</tt></b><br> - </p> - <p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p> - <p><b>Note:</b> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br> - <br></p> - <li><b><tt>server 127.127.8.0-3 mode 19</tt></b> - <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> - <p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p> - <p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p> - <p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used. - </p> - <h4>Hardware PPS support<br> - </h4> - <p>For PPS to be used, add 128 to the mode parameter.</p> - <p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p> - <h4>Monitor Data</h4> - <p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the <code>ntpq cv</code> command.<br> - Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data - and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on - a specific clock association as shown below. - </p> - <p>First let <code>ntpq</code> display the table of associations:</p> - <pre> - ntpq> as - ind assID status conf reach auth condition last_event cnt - =========================================================== - 1 19556 9154 yes yes none falsetick reachable 5 - 2 19557 9435 yes yes none candidat clock expt 3 - 3 19558 9714 yes yes none pps.peer reachable 1 - </pre> - <p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p> - <pre> - ntpq> raw - Output set to raw - </pre> - <p>Use the cv command to read the list of clock variables of a selected association:</p> - <pre> - ntpq> cv 19557 clock_var_list - </pre> - <p>The long output of the command above looks similar to:</p> - <pre> - assID=19557 status=0x0000, - clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1, - fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status, - refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version, - meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51, - gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3], - gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]" - </pre> - <p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p> - <pre> - ntpq> cv 19557 refclock_status,refclock_format,refclock_states,refclock_id, - refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction, - gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1], - gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4], - gps_health[4],gps_cfg[5] - </pre> - <p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p> - <pre> - status=0x0003, - refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION; - PPS SIGNAL; POSITION)", - refclock_format="Meinberg GPS Extended", - refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%); - running time: 21:21:39", - refclock_id="GPS", refclock_iomode="normal", - refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49 - kardel RELEASE_20060805_A", - meinberg_gps_status="[0x0000] <OK>", - gps_utc_correction="current correction 14 sec, last correction - on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000", - gps_message="/PFU3SOP-4WG14EPU0V1KA", - meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000) - UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s, - disconnect time 0000-00-00 00:00:00.0000000 (+0000) ", - gps_tot_51="week 1400 + 3 days + 42300.0000000 sec", - gps_tot_63="week 1400 + 3 days + 42294.0000000 sec", - gps_t0a="week 1400 + 5 days + 71808.0000000 sec", - gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK", - gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS", - gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK", - gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK", - gps_cfg[5]="[0x9] BLOCK II" - </pre> - <h4>Fudge Factors</h4> - <dl> - <dt><tt>time1 <i>time</i></tt> - <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type. - <dt><tt>time2 <i>time</i></tt> - <dd> - If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning). - <dd> - If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation. - <dt><tt>stratum <i>stratum</i></tt> - <dd>The stratum for this reference clock. - <dt><tt>refid <i>refid</i></tt> - <dd>The refid for this reference clock. - </dl> - <dl> - <dt><tt>flag1 { 0 | 1 }</tt> - <dd>If 0, the fudge factor <tt>time2</tt> refers to the PPS offset. - <dd>If 1, <tt>time2</tt> refers to the TRUST TIME. - <dt><tt>flag2 { 0 | 1 }</tt> - <dd>If <tt>flag2</tt> is 1, sample PPS on CLEAR instead of on ASSERT. - <dt><tt>flag3 { 0 | 1 }</tt> - <dd>If <tt>flag3</tt> is 1, link kernel PPS tracking to this refclock instance. - <dt><tt>flag4 { 0 | 1 }</tt> - <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-) - </dl> - <span style="font-weight: bold;">Note about auxiliary Sun STREAMS modules (SunOS and Solaris):</span><br> - <dl> - <dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used. - </dl> - <h4>Making your own PARSE clocks</h4> - <p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p> - <p>Additional Information</p> - <p><a href="../refclock.html">Reference Clock Drivers</a></p> - <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>Generic Reference Driver</title> + <link href="scripts/style.css" type="text/css" rel="stylesheet"> + </head> + <body> + <h3>Generic Reference Driver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->27-Jan-2014 05:31<!-- #EndDate --> + UTC</p> + <hr> + <h4>Synopsis</h4> + Address: 127.127.8.<em>u</em><br> + Reference ID: PARSE<br> + Driver ID: GENERIC<br> + Serial Port: /dev/refclock-<em>u</em>; TTY mode according to clock type<br> + PPS device: /dev/refclockpps-<em>u</em>; alternate PPS device (if not available via the serial port) + <h4>Description</h4> + The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br> + <br> + <p>The actual receiver status is mapped into various synchronization states generally used by receivers. The driver is configured to interpret the time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton 400A and low cost receivers (see <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#clocklist">list below</a>).</p> + <p>The reference clock support in NTP contains the necessary configuration tables for those receivers. In addition to supporting several different clock types and up to 4 devices, the processing of a PPS signal is also provided as a configuration option. The PPS configuration option uses the receiver-generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.</p> + <p>CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way ntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.</p> + <p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p> + <h4>Timecode variables listed by ntpq (8)</h4> + <p>The ntpq program can read and display several clock variables. These hold the following information:</p> + <dl> + <dt>refclock_format</dt> + <dd>A qualification of the decoded time code format.</dd> + <dt>refclock_states</dt> + <dd>The overall running time and the accumulated times for the clock event states.</dd> + <dt>refclock_status</dt> + <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd> + <dt>refclock_time</dt> + <dd>The local time with the offset to UTC (format HHMM).</dd> + <dt>timecode</dt> + <dd>The actual time code.</dd> + </dl> + <p>If PPS information is present, additional variables are available:</p> + <dl> + <dt>refclock_ppsskew</dt> + <dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd> + <dt>refclock_ppstime</dt> + <dd>The PPS timestamp.</dd> + </dl> + <h4>Supported Devices</h4> + <p>Currently, twenty-four clock types are supported by the PARSE driver and up to four (devices /dev/refclock-0 - /dev/refclock-3) of these clocks may be operational at any one time.<br> + A note on the implementations:</p> + <ul> + <li>These implementations were mainly done without actual access to the hardware, thus not all implementations provide full support. The development was done with the help of many kind souls who had the hardware and kindly lent me their time and patience during the development and debugging cycle. Thus for continued support and quality, direct access to the receivers is a big help. Nevertheless I am not prepared to buy these reference clocks - donations to (<a href="mailto:kardel%20%3CAT%3E%20ntp.org">kardel <AT> ntp.org</a>) are welcome as long as they work within Europe 8-). + <p>Verified implementations are:</p> + <ul> + <li>RAWDCF variants + <p>These variants have been tested for correct decoding with my own homegrown receivers. Interfacing with specific commercial products may involve some fiddling with cables. In particular, commercial RAWDCF receivers have a seemingly unlimited number of ways to draw power from the RS-232 port and to encode the DCF77 datastream. You are mainly on your own here unless I have a sample of the receiver.</p> + </li> + <li><a href="http://www.meinberg.de">Meinberg clocks</a> + <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p> + </li> + <li><a href="http://www.selinc.com">Schweitzer Engineering + Laboratories SEL-240x clocks</a> + <p>This implementation was provided and verified by SEL and <a + href="http://networktimefoundation.org">Network Time Foundation</a> + has an SEL-2407 in one of its development labs.</p> + </li> + </ul> + </li> + </ul> + <p>The pictures below have been taken from and are linked to the vendors' web pages.</p> + <a name="clocklist"></a> + <ul> + <li><strong>server 127.127.8.0-3 mode 0</strong> + <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50μs)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 1</strong> + <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50μs)</strong><br> + <a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" align="top" border="0" height="300" width="260"></a><br> + <br> + </p> + </li> + <li><a name="mode2"></a><strong>server 127.127.8.0-3 mode 2</strong> + <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</strong><br> + <a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" align="top" border="0" height="239" width="330"></a><br> + </p> + <p>This mode expects the Meinberg standard time string format with 9600/7E2.</p> + <p><strong>Note:</strong> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to allow ntpd to access those cards. For details, please refer to the README file that comes with the Meinberg driver package.<br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 3</strong> + <p><strong><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 4</strong> + <p><strong>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 5</strong> + <p><strong>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 6</strong> + <p><strong>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 7</strong> + <p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</strong><br> + <a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" align="top" border="0" height="300" width="280"></a><br> + </p> + <p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p> + <p>The University of Erlangen format is preferred. Newer Meinberg GPS receivers can be configured to transmit that format; for older devices, a special firmware version may be available.</p> + <p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p> + <p><strong>Note:</strong> mode 7 must not be used with Meinberg PCI cards; use <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode2">mode 2</a> instead.<br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 8</strong> + <p><strong><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></strong><br> + <a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" border="0" height="174" width="200"></a><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 9</strong> + <p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / <<1μs)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 10</strong> + <p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / <<1μs) (no kernel support yet)</strong><br> + <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" align="top" border="0" height="100" width="420"></a><br> + <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" border="0" height="100" width="420"></a><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 11</strong> + <p><strong>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 12</strong> + <p><strong><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></strong><br> + <a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" align="top" border="0" height="207" width="238"></a><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 13</strong> + <p><strong>Diem's Computime Radio Clock</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 14</strong> + <p><strong>RAWDCF receiver (DTR=high/RTS=low)</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 15</strong> + <p><strong>WHARTON 400A Series Clocks with a 404.2 Serial Interface</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 16</strong> + <p><strong>RAWDCF receiver (DTR=low/RTS=high) </strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 17</strong> + <p><strong>VARITEXT Receiver (MSF) </strong><br> + <br> + </p> + </li> + <li><a name="mode18"></a><strong>server 127.127.8.0-3 mode 18</strong> + <p><strong><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / <<1μs)</strong><br> + </p> + <p>This mode works without additional data communication (version, GPS status etc.) and thus should be used with multidrop, heterogeneous multiclient operation.</p> + <p><strong>Note:</strong> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 19</strong> + <p><strong>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</strong><br> + <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 20</strong> + <p><strong>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</strong><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> + <li><strong>server 127.127.8.0-3 mode 21</strong> + <p><strong>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </strong><br> + </p> + <p>See comment from mode 20 clock. <br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 22</strong> + <p><strong>MEINBERG, mode 2 but with POWERUP trust </strong><br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 23</strong> + <p><strong>MEINBERG, mode 7 but with POWERUP trust </strong><br> + </p> + </li> + <li><strong>server 127.127.8.0-3 mode 24</strong> + <p><strong><a href="http://www.selinc.com/">Schweitzer Engineering Laboratories</a></strong><br> + </p> + </li> + </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> + <p>PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronization, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus is a function of clock type.</p> + <p>Raw DCF77 pulses can be fed via a level converter to the RXD pin of an RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin connector). The telegrams are decoded and used for synchronization. DCF77 AM receivers can be bought for as little as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) and 10ms (cheap). Synchronization ceases when reception of the DCF77 signal deteriorates, since no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. During transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.</p> + <p>In addition to the PPS loopfilter control, a true PPS hardware signal can be utilized via the PPSAPI interface. PPS pulses are usually fed via a level converter to the DCD pin of an RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin connector). To select PPS support, the mode parameter is the mode value as above plus 128. If 128 is not added to the mode value, PPS will be detected to be available but will not be used. </p> + <h4>Hardware PPS support<br> + </h4> + <p>For PPS to be used, add 128 to the mode parameter.</p> + <p>If the PPS signal is fed in from a device different from the device providing the serial communication (/dev/refclock-{0..3}), this device is configured as /dev/refclockpps-{0..3}. This allows the PPS information to be fed in e.g. via the parallel port (if supported by the underlying operation system) and the date/time telegrams to be handled via the serial port.</p> + <h4>Monitor Data</h4> + <p>Clock state statistics are written hourly to the syslog service. Online information can be found by examining the clock variables via the ntpq cv command.<br> + Some devices have quite extensive additional information (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS data and makes it accessible via clock variables. To find out about additional variable names, query for the clock_var_list variable on a specific clock association as shown below. </p> + <p>First let ntpq display the table of associations:</p> + <pre> ntpq> as ind assID status conf reach auth condition last_event cnt =========================================================== 1 19556 9154 yes yes none falsetick reachable 5 2 19557 9435 yes yes none candidat clock expt 3 3 19558 9714 yes yes none pps.peer reachable 1 </pre> + <p>Then switch to raw output. This may be required because of display limitations in ntpq/ntpd - so large lists need to be retrieved in several queries.</p> + <pre> ntpq> raw Output set to raw </pre> + <p>Use the cv command to read the list of clock variables of a selected association:</p> + <pre> ntpq> cv 19557 clock_var_list </pre> + <p>The long output of the command above looks similar to:</p> + <pre> assID=19557 status=0x0000, clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1, fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status, refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version, meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51, gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3], gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]" </pre> + <p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p> + <pre> ntpq> cv 19557 refclock_status,refclock_format,refclock_states,refclock_id, refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction, gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1], gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4], gps_health[4],gps_cfg[5] </pre> + <p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p> + <pre> status=0x0003, refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION; PPS SIGNAL; POSITION)", refclock_format="Meinberg GPS Extended", refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%); running time: 21:21:39", refclock_id="GPS", refclock_iomode="normal", refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49 kardel RELEASE_20060805_A", meinberg_gps_status="[0x0000] <OK>", gps_utc_correction="current correction 14 sec, last correction on c7619a00.00000000 Sun, Jan 1 2006 0:00:00.000", gps_message="/PFU3SOP-4WG14EPU0V1KA", meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000) UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s, disconnect time 0000-00-00 00:00:00.0000000 (+0000) ", gps_tot_51="week 1400 + 3 days + 42300.0000000 sec", gps_tot_63="week 1400 + 3 days + 42294.0000000 sec", gps_t0a="week 1400 + 5 days + 71808.0000000 sec", gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK", gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS", gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK", gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK", gps_cfg[5]="[0x9] BLOCK II" </pre> + <h4>Fudge Factors</h4> + <dl> + <dt>time1 <em>time</em> </dt> + <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type. </dd> + <dt>time2 <em>time</em> </dt> + <dd> If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning). </dd> + <dd> If flag1 is 1, time2 specifies the number of seconds a receiver with a premium local oscillator can be trusted after losing synchronisation. </dd> + <dt>stratum <em>stratum</em> </dt> + <dd>The stratum for this reference clock. </dd> + <dt>refid <em>refid</em> </dt> + <dd>The refid for this reference clock. </dd> + </dl> + <dl> + <dt>flag1 { 0 | 1 } </dt> + <dd>If 0, the fudge factor time2 refers to the PPS offset. </dd> + <dd>If 1, time2 refers to the TRUST TIME. </dd> + <dt>flag2 { 0 | 1 } </dt> + <dd>If flag2 is 1, sample PPS on CLEAR instead of on ASSERT. </dd> + <dt>flag3 { 0 | 1 } </dt> + <dd>If flag3 is 1, link kernel PPS tracking to this refclock instance. </dd> + <dt>flag4 { 0 | 1 } </dt> + <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-) </dd> + </dl> + Note about auxiliary Sun STREAMS modules (SunOS and Solaris):<br> + <dl> + <dt>The timecode of these receivers can be sampled via a STREAMS module in the kernel. (The STREAMS module has been designed for use with Sun systems under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into the kernel or loaded via the loadable driver mechanism.) This STREAMS module can be adapted to convert different time code formats. Nowadays the PPSAPI mechanism is usually used. </dt> + </dl> + <h4>Making your own PARSE clocks</h4> + <p>The parse clock mechanism deviates from the way other NTP reference clocks work. For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p> + <p>Additional Information</p> + <p><a href="../refclock.html">Reference Clock Drivers</a></p> + <hr> + <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> + </body> </html> diff --git a/html/drivers/driver9.html b/html/drivers/driver9.html index 812ab13b8136..2e52af8f0817 100644 --- a/html/drivers/driver9.html +++ b/html/drivers/driver9.html @@ -11,6 +11,9 @@ <body> <h3>Magnavox MX4200 GPS Receiver</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Synopsis</h4> Address: 127.127.9.<i>u</i><br> @@ -54,4 +57,4 @@ <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/mx4200data.html b/html/drivers/mx4200data.html index 6f9ac30b6646..611da6a5f347 100644 --- a/html/drivers/mx4200data.html +++ b/html/drivers/mx4200data.html @@ -8,6 +8,9 @@ <body> <h1>MX4200 Receiver Data Format</h1> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h2>Table of Contents</h2> <ul> @@ -1071,4 +1074,4 @@ <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/oncore-shmem.html b/html/drivers/oncore-shmem.html index 8942927b1917..ec1d97441a31 100644 --- a/html/drivers/oncore-shmem.html +++ b/html/drivers/oncore-shmem.html @@ -10,6 +10,9 @@ <body> <h3>Motorola ONCORE - The Shared Memory Interface</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <h4>Introduction</h4> <p>In NMEA mode, the Oncore GPS receiver provides the user with the same information as other GPS receivers. In BINARY mode, it can provide a lot of additional information.</p> @@ -158,4 +161,4 @@ <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/scripts/footer.txt b/html/drivers/scripts/footer.txt index 89216ce97e12..d716cbf20a94 100644 --- a/html/drivers/scripts/footer.txt +++ b/html/drivers/scripts/footer.txt @@ -1,7 +1,9 @@ document.write("\ <table><tr>\ -<td width='50%' ><img src='../icons/home.gif' align='middle' alt='gif'>\ +<td width='33%' align='center'><img src='../icons/home.gif' align='middle'>\ <a href='../index.html'>Home Page</a></td>\ -<td width='50%' ><img src='../icons/mail2.gif' align='middle' alt='gif'>\ -<a href='http://www.ntp.org/contact.html'>Contacts</a></i></td>\ -</tr></table>")
\ No newline at end of file +<td width='33%' ><img src='../icons/sitemap.png' align='middle'>\ +<a href='../sitemap.html'>Site Map</a></td>\ +<td width='33%' ><img src='../icons/mail2.gif' align='middle'>\ +<a href='http://www.ntp.org/contact'>Contacts</a></td>\ +</tr></table>") diff --git a/html/drivers/scripts/style.css b/html/drivers/scripts/style.css index 096b18a6a1d9..7b90fce0048d 100644 --- a/html/drivers/scripts/style.css +++ b/html/drivers/scripts/style.css @@ -61,4 +61,4 @@ th {background: #FFFFCC; th.caption {background: #EEEEEE; color: #006600; - text-align: center;}
\ No newline at end of file + text-align: center;} diff --git a/html/drivers/tf582_4.html b/html/drivers/tf582_4.html index 6b0ce0aaa9e3..177976cff393 100644 --- a/html/drivers/tf582_4.html +++ b/html/drivers/tf582_4.html @@ -11,6 +11,9 @@ <body> <h3>European Automated Computer Time Services</h3> +<p>Last update: + <!-- #BeginDate format:En2m -->21-Oct-2010 23:44<!-- #EndDate --> + UTC</p> <hr> <p>Several European countries use the following message data format:</p> <p><font size="-1" face="Courier New">Data format<br> @@ -68,4 +71,4 @@ <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> </body> -</html>
\ No newline at end of file +</html> |