NetBSD/usr.sbin/xntp/html/driver7.html

99 lines
3.6 KiB
HTML

<!-- $NetBSD: driver7.html,v 1.1 1998/12/30 20:20:35 mcr Exp $ -->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html><head><title>
Scratchbuilt CHU Receiver
</title></head><body><h3>
Scratchbuilt CHU Receiver
</h3><hr>
<p><h4>Synopsis</h4>
<p>Address: 127.127.7.<var>u</var>
<br>Reference ID: CHU
<br>Driver ID: CHU
<br>Serial Port: <code>/dev/chu<var>u</var></code>; 300 baud, 8-bits, no
parity
<br>Features: <code>chu_clk</code>
<p><h4>Description</h4>
<p>This driver supports a shortwave receiver and special modem circuitry
described in the ./gadget directory of the xntp3 distribution. It
requires the <code>chu_clk</code> line discipline or streams module
described in the <a href="ldisc.html">Line Disciplines and Streams
Drivers</a> page. It also requires a gadget box and 300-bps modem, such
as described in the <a href="pps.html">Pulse-per-second (PPS) Signal
Interfacing</a> page.
<p>Unlike the NIST time services, whose timecode requires quite
specialized hardware to interpret, the CHU timecode can be received
directly via a serial port after demodulation. While there are currently
no known commercial CHU receivers, the hardware required to receive the
CHU timecode is fairly simple to build. While it is possible to
configure several CHU units simultaneously, this is in general not
useful.
<p>The <code>time1</code> fudge option can be used to set the CHU
propagation delay, compensate for inherent latencies in the serial port
hardware and operating system. The default value is 0.0025 seconds,
which is about right for Toronto. Values for other locations can be
calculated using the propdelay program in the util directory of the
xntp3 distribution or equivalent means.
<p>The <code>time2</code> fudge option can also be used to compensate
for inherent latencies in the serial port hardware and operating system.
The value, which defaults to zero, is in addition to the propagation
delay provided by the time1 option. The default value is 0.0002 seconds,
which is about right for typical telephone modem chips.
<p>The <code>flag1</code> option can be used to modify the averaging
algorithm used to smooth the clock indications. Ordinarily, the
algorithm picks the median of a set of samples, which is appropriate
under conditions of poor to fair radio propagation conditions. If the
clock is located relatively close to the WWV or WWVH transmitters,
setting this flag will cause the algorithm to average the set of
samples, which can reduce the residual jitter and improve accuracy.
<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>CHU</code>.
<p><dt><code>flag1 0 | 1</code>
<dd>See above.
<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>
<p>Additional Information
<p><a href="refclock.html"> Reference Clock Drivers</a>
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>