101 lines
3.4 KiB
HTML
101 lines
3.4 KiB
HTML
<!-- $NetBSD: driver26.html,v 1.1 1998/12/30 20:20:34 mcr Exp $ -->
|
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
|
|
<html><head><title>
|
|
Hewlett Packard 58503A GPS Receiver
|
|
</title></head><body><h3>
|
|
Hewlett Packard 58503A GPS Receiver
|
|
</h3><hr>
|
|
|
|
<p><h4>Synopsis</h4>
|
|
|
|
<p>Address: 127.127.26.<var>u</var>
|
|
<br>Reference ID: GPS
|
|
<br>Driver ID: GPS-HP
|
|
<br>Serial Port: <code>/dev/hpgps<var>u</var></code>; 9600 baud, 8-bits,
|
|
no parity
|
|
<br>Features: none
|
|
|
|
<p><h4>Description</h4>
|
|
|
|
<p>This driver supports the HP 58503A Time and Frequency Reference
|
|
Receiver. It uses HP SmartClock (TM) to implement an Enhanced GPS
|
|
receiver. The receiver accuracy when locked to GPS in normal operation
|
|
is better than 1 usec. The accuracy when operating in holdover is
|
|
typically better than 10 us per day. It receiver should be operated with
|
|
factory default settings. Initial driver operation: expects the receiver
|
|
to be already locked to GPS, configured and able to output timecode
|
|
format 2 messages.
|
|
|
|
<p>The driver uses the poll sequence <code>:PTIME:TCODE?</code> to get a
|
|
response from the receiver. The receiver responds with a timecode string
|
|
of ASCII printing characters, followed by a <cr><lf>,
|
|
followed by a prompt string issued by the receiver, in the following
|
|
format:
|
|
|
|
<pre>
|
|
T#yyyymmddhhmmssMFLRVcc<cr><lf>
|
|
</pre>
|
|
|
|
<p>The driver processes the response at the <cr> and
|
|
<lf><cr> and <lf>, so what the driver sees is the
|
|
prompt from the previous poll, followed by this timecode. The prompt
|
|
from the current poll is (usually) left unread until the next poll. So
|
|
(except on the very first poll) the driver sees this:
|
|
|
|
<pre>
|
|
T#yyyymmddhhmmssMFLRVcc<cr><lf>
|
|
</pre>
|
|
|
|
<p>The T is the on-time character, at 980 msec. before the next 1PPS
|
|
edge. The # is the timecode format type. We look for format 2. Without
|
|
any of the CLK or PPS stuff, then, the receiver buffer timestamp at the
|
|
<cr>y is 24 characters later, which is about 25 msec. at 9600
|
|
bps, so the first approximation for fudge time1 is nominally -0.955
|
|
seconds. This number probably needs adjusting for each machine / OS
|
|
type, so far:
|
|
|
|
-0.955000 on an HP 9000 Model 712/80 HP-UX 9.05
|
|
-0.953175 on an HP 9000 Model 370 HP-UX 9.10
|
|
|
|
<p>This receiver also provides a 1-PPS signal, but I haven't figured out
|
|
how to deal with any of the CLK or PPS stuff yet. Stay tuned.
|
|
|
|
<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 <i>time</i></code>
|
|
<dd>Specifies the time offset calibration factor, in seconds and
|
|
fraction, with default 0.0.
|
|
|
|
<p><dt><code>time2 <i>time</i></code>
|
|
<dd>Not used by this driver.
|
|
|
|
<p><dt><code>stratum <i>number</i></code>
|
|
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default
|
|
0.
|
|
|
|
<p><dt><code>refid <i>string</i></code>
|
|
<dd>Specifies the driver reference identifier, an ASCII string from one
|
|
to four characters, with default <code>GPS</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>Enable <code>ppsclock</code> line discipline/streams module if set.
|
|
|
|
<p><dt><code>flag4 0 | 1</code>
|
|
<dd>Enable <code>clockstats</code> recording if set.
|
|
|
|
</dl>
|
|
|
|
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>
|