NetBSD/usr.sbin/xntp/html/driver2.html

117 lines
3.9 KiB
HTML

<!-- $NetBSD: driver2.html,v 1.1 1998/12/30 20:20:34 mcr Exp $ -->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html><head><title>
Trak 8820 GPS Receiver
</title></head><body><h3>
Trak 8820 GPS Receiver
</h3><hr>
<p><h4>Synopsis</h4>
<p>Address: 127.127.2.<var>u</var>
<br>Reference ID: GPS
<br>Driver ID: GPS-TRAK
<br>Serial Port: <code>/dev/trak<var>u</var></code>; 9600 baud, 8-bits,
no parity
<br>Features: <code>tty_clk, ppsclock</code>
<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>For best accuracy, this radio requires the <code>tty_clk</code> line
discipline, which captures a timestamp at the <code>*</code> 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 <code>\r</code>
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>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>In operation, this driver sends a <code>RQTS\r</code> 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:
<pre>
*RQTS U,ddd:hh:mm:ss.0,q&lt;cr&gt;&lt;lf&gt;
on-time = '*'
ddd = day of year
hh:mm:ss = hours, minutes, seconds
q = quality indicator (phase error), 0-6:
0 &gt; 20 us
6 &gt; 10 us
5 &gt; 1 us
4 &gt; 100 ns
3 &gt; 10 ns
2 &lt; 10 ns
</pre>
<p>The alarm condition is indicated by <code>0</code> at <code>Q</code>,
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 <code>RQTX\r</code>
request, following which the radio sends a <code>RQTX
DONE&lt;cr&gt;&lt;lf&gt;</code> response. In the normal mode, other
control and status requests are effective, including the leap-second
status request <code>RQLS&lt;cr&gt;</code>. The radio responds with
<code>RQLS yy,mm,dd&lt;cr&gt;&lt;lf&gt;</code>, where
<code>yy,mm,dd</code> are the year, month and day. Presumably, this
gives the epoch of the next leap second, <code>RQLS 00,00,00</code> 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 <code>flag4</code> fudge flag, every received
timecode is written as-is to the <code>clockstats</code> file.
<p><h4>Fudge Factors</h4>
<dl>
<dt><code>time1 <var>time</var></code>
<dd>Specifies the time offset calibration factor, in seconds and
fraction, with default 0.0.
<p><dt><code>time2 <var>time</var></code>
<dd>Not used by this driver.
<p><dt><code>stratum <var>number</var></code>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default
0.
<p><dt><code>refid <var>string</var></code>
<dd>Specifies the driver reference identifier, an ASCII string from one
to four characters, with default <code>TRAK</code>.
<p><dt><code>flag1 0 | 1</code>
<dd>Not used by this driver.
<p><dt><code>flag2 0 | 1</code>
<dd>Not used by this driver.
<p><dt><code>flag3 0 | 1</code>
<dd>Not used by this driver.
<p><dt><code>flag4 0 | 1</code>
<dd>Enable <code>clockstats</code> recording if set.
<p>Additional Information
<p><a href="refclock.html"> Reference Clock Drivers</a>
</dl>
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>