* html/leap.htm: Added.
* html/index.htm: Update.
* html/driver7.htm: Update.
* html/driver6.htm: Update.
* html/driver36.htm: Update.
* html/audio.htm: Update.
* html/y2k.htm: Removed.
From Dave Mills.
bk: 3ad938dfaS2kvx3KfLSz7QVeBWGdkA
+2001-04-15 Harlan Stenn <stenn@whimsy.udel.edu>
+
+ * html/leap.htm: Added.
+ * html/index.htm: Update.
+ * html/driver7.htm: Update.
+ * html/driver6.htm: Update.
+ * html/driver36.htm: Update.
+ * html/audio.htm: Update.
+ * html/y2k.htm: Removed.
+ From Dave Mills.
+
2001-04-14 Harlan Stenn <stenn@whimsy.udel.edu>
* acconfig.h: Lose extra declarations of PACKAGE and VERSION.
-<html><head><title>
-Reference Clock Audio Drivers
-</title></head><body><h3>
-Reference Clock Audio Drivers
-</h3>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Reference Clock Audio Drivers</title>
+</head>
+<body>
+<h3>Reference Clock Audio Drivers</h3>
-<img align=left src=pic/radio2.jpg>
+<img align="left" src="pic/radio2.jpg" alt="gif">
-<p>Make a little noise here.
-<br clear=left><hr>
+<p>Make a little noise here.<br clear="left">
+</p>
+<hr>
<p>There are some applications in which the computer time can be
disciplined to an audio signal, rather than a serial timecode and
-communications port or special purpose bus peripheral. This is useful in
-such cases where the audio signal is sent over a telephone circuit, for
-example, or received directly from a shortwave receiver. In such cases
-the audio signal can be connected via an ordinary sound card or
-baseboard audio codec. The suite of NTP reference clock drivers
-currently includes three drivers suitable for these applications. They
-include a driver for the Inter Range Instrumentation Group (IRIG)
-signals produced by most radio clocks and timing devices, another for
-the Canadian time/frequency radio station CHU and a third for the NIST
+communications port or special purpose bus peripheral. This is
+useful in such cases where the audio signal is sent over a
+telephone circuit, for example, or received directly from a
+shortwave receiver. In such cases the audio signal can be connected
+via an ordinary sound card or baseboard audio codec. The suite of
+NTP reference clock drivers currently includes three drivers
+suitable for these applications. They include a driver for the
+Inter Range Instrumentation Group (IRIG) signals produced by most
+radio clocks and timing devices, another for the Canadian
+time/frequency radio station CHU and a third for the NIST
time/frequency radio stations WWV and WWVH. The radio drivers are
-designed to work with ordinary inexpensive shortwave radios and may be
-one of the least expensive ways to build a good primary time server.
+designed to work with ordinary inexpensive shortwave radios and may
+be one of the least expensive ways to build a good primary time
+server.</p>
<p>All three drivers make ample use of sophisticated digital signal
-processing algorithms designed to efficiently extract timing signals
-from noise and interference. The radio station drivers in particular
-implement optimum linear demodulation and decoding techniques, including
-maximum likelihood and soft-decision methods. The documentation page for
-each driver contains an in-depth discussion on the algorithms and
-performance expectations. In some cases the algorithms are further
-analyzed, modelled and evaluated in a technical report.
+processing algorithms designed to efficiently extract timing
+signals from noise and interference. The radio station drivers in
+particular implement optimum linear demodulation and decoding
+techniques, including maximum likelihood and soft-decision methods.
+The documentation page for each driver contains an in-depth
+discussion on the algorithms and performance expectations. In some
+cases the algorithms are further analyzed, modelled and evaluated
+in a technical report.</p>
<p>Currently, the audio drivers are compatible with Sun operating
systems, including Solaris and SunOS, and the native audio codec
-interface supported by these systems. In fact, the interface is quite
-generic and support for other systems, in particular the various Unix
-generics, should not be difficult. Volunteers are solicited.
-
-<p>The audio drivers include a number of common features designed to
-groom input signals, suppress spikes and normalize signal levels. An
-automatic gain control (AGC) feature provides protection against
-overdriven or underdriven input signals. It is designed to maintain
-adequate demodulator signal amplitude while avoiding occasional noise
-spikes. In order to assure reliable operation, the signal level must be
-in the range where the audio gain control is effective. In general, this
-means the input signal level must be such as to cause the AGC to set the
-gain somewhere in the middle of the range from 0 to 255, as indicated in
-the timecode displayed by the <tt>ntpq</tt> program.
+interface supported by these systems. In fact, the interface is
+quite generic and support for other systems, in particular the
+various Unix generics, should not be difficult. Volunteers are
+solicited.</p>
+
+<p>The audio drivers include a number of common features designed
+to groom input signals, suppress spikes and normalize signal
+levels. An automatic gain control (AGC) feature provides protection
+against overdriven or underdriven input signals. It is designed to
+maintain adequate demodulator signal amplitude while avoiding
+occasional noise spikes. In order to assure reliable operation, the
+signal level must be in the range where the audio gain control is
+effective. In general, this means the input signal level must be
+such as to cause the AGC to set the gain somewhere in the middle of
+the range from 0 to 255, as indicated in the timecode displayed by
+the <tt>ntpq</tt> program.</p>
<p>The drivers operate by disciplining a logical clock based on the
codec sample clock to the audio signal as received. This is done by
-stuffing or slipping samples as required to maintain exact frequency to
-the order of 0.1 PPM. In order for the driver to reliably lock on the
-audio signal, the sample clock frequency tolerance must be less than 250
-PPM (.025 percent) for the IRIG driver and half that for the radio
-drivers. The largest error observed so far is about 60 PPM, but it is
-possible some sound cards or codecs may exceed that value.
+stuffing or slipping samples as required to maintain exact
+frequency to the order of 0.1 PPM. In order for the driver to
+reliably lock on the audio signal, the sample clock frequency
+tolerance must be less than 250 PPM (.025 percent) for the IRIG
+driver and half that for the radio drivers. The largest error
+observed so far is about 60 PPM, but it is possible some sound
+cards or codecs may exceed that value.</p>
<p>The drivers include provisions to select the input port and to
monitor the input signal. The <tt>fudge flag 2</tt> selects 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. The
-<tt>fudge flag 3</tt> enables the input signal monitor using the
-previously selected output port and output gain. Both of these flags can
-be set in the configuration file or remotely using the <tt>ntpdc</tt>
-utility program.
-
-<H4>Shortwave Radio Drivers</H4>
-
-<p>The WWV/H and CHU audio drivers require an external shortwave radio
-with the radio output - speaker or headphone jack - connected to either
-the microphone or line-in port on the computer. There is some degree of
-art in setting up the radio and antenna and getting the setup to work.
-While the drivers are highly sophisticated and efficient in extracting
-timing signals from noise and interference, it always helps to have as
-clear a signal as possible.
-
-<p>The most important factor affecting the radio signal is the antenna.
-It need not be long - even 15 feet is enough if it is located outside of
-a metal frame building, preferably on the roof, and away from metallic
-objects. An ordinary CB whip mounted on a PVC pipe and wooden X-frame on
-the roof should work well with most portable radios, as they are
-optimized for small antennas.
+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.
+The <tt>fudge flag 3</tt> enables the input signal monitor using
+the previously selected output port and output gain. Both of these
+flags can be set in the configuration file or remotely using the
+<tt>ntpdc</tt> utility program.</p>
+
+<h4>Shortwave Radio Drivers</h4>
+
+<p>The WWV/H and CHU audio drivers require an external shortwave
+radio with the radio output - speaker or headphone jack - connected
+to either the microphone or line-in port on the computer. There is
+some degree of art in setting up the radio and antenna and getting
+the setup to work. While the drivers are highly sophisticated and
+efficient in extracting timing signals from noise and interference,
+it always helps to have as clear a signal as possible.</p>
+
+<p>The most important factor affecting the radio signal is the
+antenna. It need not be long - even 15 feet is enough if it is
+located outside of a metal frame building, preferably on the roof,
+and away from metallic objects. An ordinary CB whip mounted on a
+PVC pipe and wooden X-frame on the roof should work well with most
+portable radios, as they are optimized for small antennas.</p>
<p>The radio need not be located near the computer; in fact, it
generally works better if the radio is outside the near field of
computers and other electromagnetic noisemakers. It can be in the
-elevator penthouse connected by house wiring, which can also be used to
-power the radio. A couple of center-tapped audio transformers will
-minimize noise pickup and provide phantom power to the radio with return
-via the AC neutral wire.
+elevator penthouse connected by house wiring, which can also be
+used to power the radio. A couple of center-tapped audio
+transformers will minimize noise pickup and provide phantom power
+to the radio with return via the AC neutral wire.</p>
<p>The WWV/H and CHU transmitters operate on several frequencies
simultaneously, so that in most parts of North America at least one
-frequency supports propagation to the receiver location at any given
-hour. While both drivers support the ICOM CI-V radio interface and can tune the radio automatically, computer-tunable radios are expensive and probably not cost effective compared to a GPS receiver. So, the radio frequency must usually be fixed and chosen by compromise.
+frequency supports propagation to the receiver location at any
+given hour. While both drivers support the ICOM CI-V radio
+interface and can tune the radio automatically, computer-tunable
+radios are expensive and probably not cost effective compared to a
+GPS receiver. So, the radio frequency must usually be fixed and
+chosen by compromise.</p>
-<p>Shortwave (3-30 MHz) radio propagation phenomena are well known to
-shortwave enthusiasts. The phenomena generally obey the following rules:
+<p>Shortwave (3-30 MHz) radio propagation phenomena are well known
+to shortwave enthusiasts. The phenomena generally obey the
+following rules:</p>
<ul>
+<li>The optimum frequency is higher in daytime than nighttime,
+stays high longer on summer days and low longer on winter
+nights.</li>
-<p><li>The optimum frequency is higher in daytime than nighttime, stays
-high longer on summer days and low longer on winter nights.
+<li>Transitions between daytime and nightime conditions generally
+occur somewhat after sunrise and sunset at the midpoint of the path
+from transmitter to receiver.</li>
-<p><li>Transitions between daytime and nightime conditions generally
-occur somewhat after sunrise and sunset at the midpoint of the path from
-transmitter to receiver.
+<li>Ambient noise (static) on the lower frequencies follows the
+thunderstorm season, so is higher on summer afternoons and
+evenings.</li>
-<p><li>Ambient noise (static) on the lower frequencies follows the
-thunderstorm season, so is higher on summer afternoons and evenings.
-
-<p><li>The lower frequency bands are best for shorter distances, while
-the higher bands are best for longer distances.
-
-<p><li>The optimum frequencies are higher at the peak of the 11-year
-sunspot cycle and lower at the trough. The current sunspot cycle should
-peak in the first couple of years beginning the century.
+<li>The lower frequency bands are best for shorter distances, while
+the higher bands are best for longer distances.</li>
+<li>The optimum frequencies are higher at the peak of the 11-year
+sunspot cycle and lower at the trough. The current sunspot cycle
+should peak in the first couple of years beginning the
+century.</li>
</ul>
-The best way to choose a frequency is to listen at various times over
-the day and determine the best highest (daytime) and lowest (nighttime)
-frequencies. Then, assuming one is available, choose the highest
-frequency between these frequencies. This strategy assumes that the high
-frequency is more problematic than the low, that the low frequency
-probably comes with severe multipath and static, and insures that
-probably twice a day the chosen frequency will work. For instance, on
-the east coast the best compromise CHU frequency is probably 7335 kHz
-and the best WWV frequency is probably 15 MHz.
+The best way to choose a frequency is to listen at various times
+over the day and determine the best highest (daytime) and lowest
+(nighttime) frequencies. Then, assuming one is available, choose
+the highest frequency between these frequencies. This strategy
+assumes that the high frequency is more problematic than the low,
+that the low frequency probably comes with severe multipath and
+static, and insures that probably twice a day the chosen frequency
+will work. For instance, on the east coast the best compromise CHU
+frequency is probably 7335 kHz and the best WWV frequency is
+probably 15 MHz.
<h4>Debugging Aids</h4>
-<p>The audio drivers include extensive debugging support to help hook up
-the audio signals and monitor the driver operations. The documentation
-page for each driver describes the various messages that can be produced
-either in real-time or written to the <tt>clockstats</tt> file for
-later analysis. Of particular help in verifying signal connections and
-compatibility is a provision to monitor the signal via headphones or
-speaker.
-
-
-<p>The drivers write a synthesized timecode to the <tt>clockstats</tt>
-file each time the clock is set or verified and at other times if verbose monitoring is enabled. The format includes several fixed-length fields defining the Gregorian time to the millisecond, together with additional variable-length fields specific to each driver. The data include the intervals since the clock was last set or verified, the audio gain and various state variables and counters specific to each driver.
-
-<H4>Additional Information</H4>
-
-<A HREF="refclock.htm">Reference Clock Drivers</A>
-<br><A HREF="driver7.htm">Radio CHU Audio Demodulator/Decoder</A>
-<br><A HREF="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</A>
-<br><A HREF="driver6.htm">IRIG Audio Decoder</A>
+<p>The audio drivers include extensive debugging support to help
+hook up the audio signals and monitor the driver operations. The
+documentation page for each driver describes the various messages
+that can be produced either in real-time or written to the <tt>
+clockstats</tt> file for later analysis. Of particular help in
+verifying signal connections and compatibility is a provision to
+monitor the signal via headphones or speaker.</p>
+
+<p>The drivers write a synthesized timecode to the <tt>
+clockstats</tt> file each time the clock is set or verified and at
+other times if verbose monitoring is enabled. The format includes
+several fixed-length fields defining the Gregorian time to the
+millisecond, together with additional variable-length fields
+specific to each driver. The data include the intervals since the
+clock was last set or verified, the audio gain and various state
+variables and counters specific to each driver.</p>
+
+<h4>Additional Information</h4>
+
+<a href="refclock.htm">Reference Clock Drivers</a> <br>
+<a href="driver7.htm">Radio CHU Audio Demodulator/Decoder</a> <br>
+<a href="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</a>
+<br>
+<a href="driver6.htm">IRIG Audio Decoder</a>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-Radio WWV/H Audio Demodulator/Decoder
-</title></head><body><h3>
-Radio WWV/H Audio Demodulator/Decoder
-</h3><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Radio WWV/H Audio Demodulator/Decoder</title>
+</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>WWV</tt> or <tt>WWVH</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>
+Address: 127.127.36.<i>u</i> <br>
+Reference ID: <tt>WWV</tt> or <tt>WWVH</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 data encoded in
-shortwave radio transmissions from NIST time/frequency stations WWV in
-Ft. Collins, CO, and WWVH in Kauai, HI. Transmissions are made
+shortwave radio transmissions from NIST time/frequency stations WWV
+in Ft. Collins, CO, and WWVH in Kauai, HI. Transmissions are made
continuously on 2.5, 5, 10, 15 and 20 MHz. 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 night.
-The performance of this driver when tracking one of the stations is
-ordinarily better than 1 ms in time with frequency drift less than 0.5
-PPM when not tracking either station.
+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 night. The performance of this driver when tracking one of the
+stations is ordinarily better than 1 ms in time with frequency
+drift less than 0.5 PPM when not tracking either station.
<p>The demodulation and decoding algorithms used by this driver are
-based on a machine language program developed for the TAPR DSP93 DSP
-unit, which uses the TI 320C25 DSP chip. The analysis, design and
-performance of the program running on this unit is described in: Mills,
-D.L. A precision radio clock for WWV transmissions. Electrical
-Engineering Report 97-8-1, University of Delaware, August 1997, 25 pp.
-Available from <a href=http://www.eecis.udel.edu/~mills/reports.htm>
-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 somewhat to improve
-performance under weak signal conditions and to provide an automatic
-station identification feature.
-
-<p>This driver incorporates several features in common with other audio
-drivers such as described in the <a href=driver7.htm>Radio CHU Audio
-Demodulator/Decoder</a> and the <a href=driver6.htm>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.htm>Reference Clock Audio Drivers</a>
-page.
-
-<p>The WWV signal format is described in NIST Special Publication 432
-(Revised 1990). It consists of three elements, a 5-ms, 1000-Hz pulse,
-which occurs at the beginning of each second, a 800-ms, 1000-Hz pulse,
-which occurs at the beginning of each minute, and a pulse-width
-modulated 100-Hz subcarrier for the data bits, one bit per second. The
-WWVH format is identical, except that the 1000-Hz pulses are sent at
-1200 Hz. Each minute encodes nine BCD digits for the time of century
-plus seven bits for the daylight savings time (DST) indicator, leap
-warning indicator and DUT1 correction.
+based on a machine language program developed for the TAPR DSP93
+DSP unit, which uses the TI 320C25 DSP chip. The analysis, design
+and performance of the program running on this unit is described
+in: Mills, D.L. A precision radio clock for WWV transmissions.
+Electrical Engineering Report 97-8-1, University of Delaware,
+August 1997, 25 pp. Available from <a href=
+"http://www.eecis.udel.edu/~mills/reports.htm">
+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
+somewhat to improve performance under weak signal conditions and to
+provide an automatic station identification feature.</p>
+
+<p>This driver incorporates several features in common with other
+audio drivers such as described in the <a href="driver7.htm">Radio
+CHU Audio Demodulator/Decoder</a> and the <a href="driver6.htm">
+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.htm">Reference Clock Audio Drivers</a> page.</p>
+
+<p>The WWV signal format is described in NIST Special Publication
+432 (Revised 1990). It consists of three elements, a 5-ms, 1000-Hz
+pulse, which occurs at the beginning of each second, a 800-ms,
+1000-Hz pulse, which occurs at the beginning of each minute, and a
+pulse-width modulated 100-Hz subcarrier for the data bits, one bit
+per second. The WWVH format is identical, except that the 1000-Hz
+pulses are sent at 1200 Hz. Each minute encodes nine BCD digits for
+the time of century plus seven bits for the daylight savings time
+(DST) indicator, leap warning indicator and DUT1 correction.</p>
<h4>Program Architecture</h4>
-<p>As in the original program, the clock discipline is modelled as a
-Markov process, with probabilistic state transitions corresponding to a
-conventional clock and the probabilities of received decimal digits. The
-result is a performance level which results in very high accuracy and
-reliability, even under conditions when the minute beep of the signal,
-normally its most prominent feature, can barely be detected by ear with
-a shortwave receiver.
-
-<p>The analog audio signal from the shortwave radio is sampled at 8000
-Hz and converted to digital representation. The 1000/1200-Hz pulses and
-100-Hz subcarrier are first separated using two IIR filters, a 600-Hz
-bandpass filter centered on 1100 Hz and a 150-Hz lowpass filter. The
-minute sync pulse is extracted using a 800-ms synchronous matched filter
-and pulse grooming logic which discriminates between WWV and WWVH
-signals and noise. The second sync pulse is extracted using a 5-ms FIR
-matched filter and 8000-stage comb filter.
-
-<p>The phase of the 100-Hz subcarrier relative to the second sync pulse
-is fixed at the transmitter; however, the audio highpass filter in most
-radios affects the phase response at 100 Hz in unpredictable ways. The
-driver adjusts for each radio using two 170-ms synchronous matched
-filters. The I (in-phase) filter is used to demodulate the subcarrier
-envelope, while the Q (quadrature-phase) filter is used in a tracking
-loop to discipline the codec sample clock and thus the demodulator
-phase.
+<p>As in the original program, the clock discipline is modelled as
+a Markov process, with probabilistic state transitions
+corresponding to a conventional clock and the probabilities of
+received decimal digits. The result is a performance level which
+results in very high accuracy and reliability, even under
+conditions when the minute beep of the signal, normally its most
+prominent feature, can barely be detected by ear with a shortwave
+receiver.</p>
+
+<p>The analog audio signal from the shortwave radio is sampled at
+8000 Hz and converted to digital representation. The 1000/1200-Hz
+pulses and 100-Hz subcarrier are first separated using two IIR
+filters, a 600-Hz bandpass filter centered on 1100 Hz and a 150-Hz
+lowpass filter. The minute sync pulse is extracted using a 800-ms
+synchronous matched filter and pulse grooming logic which
+discriminates between WWV and WWVH signals and noise. The second
+sync pulse is extracted using a 5-ms FIR matched filter and
+8000-stage comb filter.</p>
+
+<p>The phase of the 100-Hz subcarrier relative to the second sync
+pulse is fixed at the transmitter; however, the audio highpass
+filter in most radios affects the phase response at 100 Hz in
+unpredictable ways. The driver adjusts for each radio using two
+170-ms synchronous matched filters. The I (in-phase) filter is used
+to demodulate the subcarrier envelope, while the Q
+(quadrature-phase) filter is used in a tracking loop to discipline
+the codec sample clock and thus the demodulator phase.</p>
<p>The data bit probabilities are determined from the subcarrier
envelope using a threshold-corrected slicer. The averaged envelope
-amplitude 30 ms from the beginning of the second establishes the minimum
-(noise floor) value, while the amplitude 200 ms from the beginning
-establishes the maximum (signal peak) value. The slice level is midway
-between these two values. The negative-going envelope transition at the
-slice level establishes the length of the data pulse, which in turn
-establish probabilities for binary zero (P0) or binary one (P1). The
-values are established by linear interpolation between the pulse lengths
-for P0 (300 ms) and P1 (500 ms) so that the sum is equal to one. If the
-driver has not synchronized to the minute pulse, or if the data bit
-amplitude, signal/noise ratio (SNR) or length are below thresholds, the
-bit is considered invalid and all three probabilities are set to zero.
-
-<p>The difference between the P1 and P0 probabilities, or likelihood,
-for each data bit 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, an average value larger than a positive threshold is interpreted
-as a hit on one and a value smaller than a negative threshold as a hit
-on zero. Values between the two thresholds, which can occur due to
-signal fades or loss of signal, are interpreted as a miss, and result in
-no change of indication.
-
-<p>The BCD digit in each digit position of the timecode is represented
-as four data bits, all of which must be valid for the digit itself to be
-considered valid. If so, the bits are correlated with the bits
-corresponding to each of the valid decimal digits in this position. If
-the digit is 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 of the averaged
-values then becomes the maximum likelihood selection for this position
-and the ratio of the maximum over the next lower value becomes the
-likelihood ratio.
-
-<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>Each row of the decoding matrix also includes a compare counter and
-the difference (modulo the radix) between the current clock digit and
-most recently determined maximum likelihood digit. If a digit likelihood
-exceeds the decision level and the difference is constant 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>The logical master clock is derived from the audio codec clock. Its
-frequency is disciplined by a frequency-lock loop (FLL) which operates
-independently of the data recovery functions. At averaging intervals
-determined by the measured jitter, the frequency error is calculated as
-the difference between the most recent and the current second epoch
-divided by the interval. The sample clock frequency is then corrected by
-this amount using an exponential average. When first started, the
-frequency averaging interval is eight seconds, in order to compensate
-for intrinsic codec clock frequency offsets up to 125 PPM. Under most
-conditions, the averaging interval doubles in stages from the initial
-value to over 1000 seconds, which results in an ultimate frequency
-precision of 0.125 PPM, or about 11 ms/day.
+amplitude 30 ms from the beginning of the second establishes the
+minimum (noise floor) value, while the amplitude 200 ms from the
+beginning establishes the maximum (signal peak) value. The slice
+level is midway between these two values. The negative-going
+envelope transition at the slice level establishes the length of
+the data pulse, which in turn establish probabilities for binary
+zero (P0) or binary one (P1). The values are established by linear
+interpolation between the pulse lengths for P0 (300 ms) and P1 (500
+ms) so that the sum is equal to one. If the driver has not
+synchronized to the minute pulse, or if the data bit amplitude,
+signal/noise ratio (SNR) or length are below thresholds, the bit is
+considered invalid and all three probabilities are set to zero.</p>
+
+<p>The difference between the P1 and P0 probabilities, or
+likelihood, for each data bit 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, an average value larger than a
+positive threshold is interpreted as a hit on one and a value
+smaller than a negative threshold as a hit on zero. Values between
+the two thresholds, which can occur due to signal fades or loss of
+signal, are interpreted as a miss, and result in no change of
+indication.</p>
+
+<p>The BCD digit in each digit position of the timecode is
+represented as four data bits, all of which must be valid for the
+digit itself to be considered valid. If so, the bits are correlated
+with the bits corresponding to each of the valid decimal digits in
+this position. If the digit is 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 of the averaged values then becomes the maximum
+likelihood selection for this position and the ratio of the maximum
+over the next lower value becomes the likelihood ratio.</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 difference (modulo the radix) between the current clock
+digit and most recently determined maximum likelihood digit. If a
+digit likelihood exceeds the decision level and the difference is
+constant for a number of successive minutes in any row, the maximum
+likelihood digit replaces the clock digit in that row. When this
+condition is true for all rows and the second epoch has been
+reliably determined, the clock is set (or verified if it has
+already been set) and delivers correct time to the integral second.
+The fraction within the second is derived from the logical master
+clock, which runs at 8000 Hz and drives all system timing
+functions.</p>
+
+<p>The logical master clock is derived from the audio codec clock.
+Its frequency is disciplined by a frequency-lock loop (FLL) which
+operates independently of the data recovery functions. At averaging
+intervals determined by the measured jitter, the frequency error is
+calculated as the difference between the most recent and the
+current second epoch divided by the interval. The sample clock
+frequency is then corrected by this amount using an exponential
+average. When first started, the frequency averaging interval is
+eight seconds, in order to compensate for intrinsic codec clock
+frequency offsets up to 125 PPM. Under most conditions, the
+averaging interval doubles in stages from the initial value to over
+1000 seconds, which results in an ultimate frequency precision of
+0.125 PPM, or about 11 ms/day.</p>
<p>It is important that the logical clock frequency is stable and
-accurately determined, since in most applications the shortwave radio
-will be tuned to a fixed frequency where WWV or WWVH signals are not
-available throughout the day. In addition, in some parts of the US,
-especially on the west coast, signals from either or both WWV and WWVH
-may be available at different times or even at the same time. Since the
-propagation times from either station are almost always different, each
-station must be reliably identified before attempting to set the clock.
-
-<p>Station identification uses the 800-ms minute pulse transmitted by
-each station. In the acquisition phase the entire minute is searched
-using both the WWV and WWVH using matched filters and a pulse gate
-discriminator similar to that found in radar acquisition and tracking
-receivers. The peak amplitude found determines a range gate and window
-where the next pulse is expected to be found. The minute is scanned
-again to verify the peak is indeed in the window and with acceptable
-amplitude, SNR and jitter. At this point the receiver begins to track
-the second sync pulse and operate as above until the clock is set.
-
-<p>Once the minute is synchronized, the range gate is fixed and only
-energy within the window is considered for the minute sync pulse. A
-compare counter increments by one if the minute pulse has acceptable
-amplitude, SNR and jitter and decrements otherwise. This is used as a
-quality indicator and reported in the timecode and also for the autotune
-function described below.
+accurately determined, since in most applications the shortwave
+radio will be tuned to a fixed frequency where WWV or WWVH signals
+are not available throughout the day. In addition, in some parts of
+the US, especially on the west coast, signals from either or both
+WWV and WWVH may be available at different times or even at the
+same time. Since the propagation times from either station are
+almost always different, each station must be reliably identified
+before attempting to set the clock.</p>
+
+<p>Station identification uses the 800-ms minute pulse transmitted
+by each station. In the acquisition phase the entire minute is
+searched using both the WWV and WWVH using matched filters and a
+pulse gate discriminator similar to that found in radar acquisition
+and tracking receivers. The peak amplitude found determines a range
+gate and window where the next pulse is expected to be found. The
+minute is scanned again to verify the peak is indeed in the window
+and with acceptable amplitude, SNR and jitter. At this point the
+receiver begins to track the second sync pulse and operate as above
+until the clock is set.</p>
+
+<p>Once the minute is synchronized, the range gate is fixed and
+only energy within the window is considered for the minute sync
+pulse. A compare counter increments by one if the minute pulse has
+acceptable amplitude, SNR and jitter and decrements otherwise. This
+is used as a quality indicator and reported in the timecode and
+also for the autotune function described below.</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 propagation
-medium. Conventional wisdom is that synchronization via the HF medium is
-good only to a millisecond under the best propagation conditions. The
-performance of the NTP daemon disciplined by the driver is clearly
-better than this, even under marginal conditions. Ordinarily, with
-marginal to good signals and a frequency averaging interval of 1024 s,
-the frequency is stabilized within 0.1 PPM and the time within 125 <font
-face=Symbol>m</font>s. The frequency stability characteristic is highly
-important, since the clock may have to free-run for several hours before
-reacquiring the WWV/H signal.
-
-<p>The expected accuracy over a typical day was determined using the
-DSP93 and an oscilloscope and cesium oscillator calibrated with a GPS
-receiver. With marginal signals and allowing 15 minutes for initial
-synchronization and frequency compensation, the time accuracy determined
-from the WWV/H second sync pulse was reliably within 125 <font
-face=Symbol>m</font>s. In the particular DSP-93 used for program
-development, the uncorrected CPU clock frequency offset was
-45.8±0.1 PPM. Over the first hour after initial synchronization,
-the clock frequency drifted about 1 PPM as the frequency averaging
-interval increased to the maximum 1024 s. Once reaching the maximum, the
-frequency wandered over the day up to 1 PPM, but it is not clear whether
-this is due to the stability of the DSP-93 clock oscillator or the
-changing height of the ionosphere. Once the frequency had stabilized and
-after loss of the WWV/H signal, the frequency drift was less than 0.5
-PPM, which is equivalent to 1.8 ms/h or 43 ms/d. This resulted in a step
-phase correction up to several milliseconds when the signal returned.
-
-<p>The measured propagation delay from the WWV transmitter at Boulder,
-CO, to the receiver at Newark, DE, is 23.5±0.1 ms. This is
-measured to the peak of the pulse after the second sync comb filter and
-includes components due to the ionospheric propagation delay, nominally
-8.9 ms, communications receiver delay and program delay. The propagation
-delay can be expected to change about 0.2 ms over the day, as the result
-of changing ionosphere height. The DSP93 program delay was measured at
-5.5 ms, most of which is due to the 400-Hz bandpass filter and 5-ms
-matched filter. Similar delays can be expected of this driver.
+<p>It is the intent of the design that the accuracy and stability
+of the indicated time be limited only by the characteristics of the
+propagation medium. Conventional wisdom is that synchronization via
+the HF medium is good only to a millisecond under the best
+propagation conditions. The performance of the NTP daemon
+disciplined by the driver is clearly better than this, even under
+marginal conditions. Ordinarily, with marginal to good signals and
+a frequency averaging interval of 1024 s, the frequency is
+stabilized within 0.1 PPM and the time within 125 <font face=
+"Symbol">m</font>s. The frequency stability characteristic is
+highly important, since the clock may have to free-run for several
+hours before reacquiring the WWV/H signal.</p>
+
+<p>The expected accuracy over a typical day was determined using
+the DSP93 and an oscilloscope and cesium oscillator calibrated with
+a GPS receiver. With marginal signals and allowing 15 minutes for
+initial synchronization and frequency compensation, the time
+accuracy determined from the WWV/H second sync pulse was reliably
+within 125 <font face="Symbol">m</font>s. In the particular DSP-93
+used for program development, the uncorrected CPU clock frequency
+offset was 45.8±0.1 PPM. Over the first hour after initial
+synchronization, the clock frequency drifted about 1 PPM as the
+frequency averaging interval increased to the maximum 1024 s. Once
+reaching the maximum, the frequency wandered over the day up to 1
+PPM, but it is not clear whether this is due to the stability of
+the DSP-93 clock oscillator or the changing height of the
+ionosphere. Once the frequency had stabilized and after loss of the
+WWV/H signal, the frequency drift was less than 0.5 PPM, which is
+equivalent to 1.8 ms/h or 43 ms/d. This resulted in a step phase
+correction up to several milliseconds when the signal returned.</p>
+
+<p>The measured propagation delay from the WWV transmitter at
+Boulder, CO, to the receiver at Newark, DE, is 23.5±0.1 ms.
+This is measured to the peak of the pulse after the second sync
+comb filter and includes components due to the ionospheric
+propagation delay, nominally 8.9 ms, communications receiver delay
+and program delay. The propagation delay can be expected to change
+about 0.2 ms over the day, as the result of changing ionosphere
+height. The DSP93 program delay was measured at 5.5 ms, most of
+which is due to the 400-Hz bandpass filter and 5-ms matched filter.
+Similar delays can be expected of this driver.</p>
<h4>Program Operation</h4>
-The driver begins operation immediately upon startup. It first searches
-for one or both of the stations WWV and WWVH and attempts to acquire
-minute sync. This may take some fits and starts, as the driver expects
-to see three 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 three good minutes are
-found.
-
-<p>The driver then acquires second sync, which can take up to several
-minutes, depending on signal quality. At the same time the driver
-accumulates likelihood values for each of the nine digits of the clock,
-plus the seven miscellaneous bits included in the WWV/H transmission
-format. The minute units digit is decoded first and, when five
-repetitions have compared correctly, the remaining eight digits are
-decoded. When five repetitions of all nine digits have decoded
-correctly, which normally takes 15 minutes with good signals and up to
-an hour when buried in noise, and the second sync alarm has not been
-raised for two minutes, the clock is set (or verified) and is selectable
-to discipline the system clock.
-
-<p>As long as the clock is set or verified, the system clock offsets are
-provided once each second to the reference clock interface, where they
-are saved in a buffer. At the end of each minute, the buffer samples are
-groomed by the median filter and trimmed-mean averaging functions. Using
-these functions, the system clock can in principle be disciplined to a
-much finer resolution than the 125-<font face=Symbol>m</font>s sample
-interval would suggest, although the ultimate accuracy is probably
-limited by propagation delay variations as the ionspheric height varies
-throughout the day and night.
-
-<p>As long as signals are available, the clock frequency is disciplined
-for use during times when the signals are unavailable. The algorithm
-refines the frequency offset using increasingly longer averaging
-intervals to 1024 s, where the precision is about 0.1 PPM. With good
-signals, it takes well over two hours to reach this degree of precision;
-however, it can take many more hours than this in case of marginal
-signals. Once reaching the limit, the algorithm will follow frequency
-variations due to temperature fluctuations and ionospheric height
-variations.
-
-<p>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
-is first started, the NTP reference identifier appears as <tt>NONE</tt>.
-When the driver has acquired one or both stations and mitigated which
-one is best, it sets the station identifier in the timecode as described
-below. In addition, the NTP reference identifier is set to the station
-callsign. If the propagation delays has 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 will be
-seamless.
+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 sync. This may take some fits and starts, as the
+driver expects to see three 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 three good minutes are found.
+
+<p>The driver then acquires second sync, which can take up to
+several minutes, depending on signal quality. At the same time the
+driver accumulates likelihood values for each of the nine digits of
+the clock, plus the seven miscellaneous bits included in the WWV/H
+transmission format. The minute units digit is decoded first and,
+when five repetitions have compared correctly, the remaining eight
+digits are decoded. When five repetitions of all nine digits have
+decoded correctly, which normally takes 15 minutes with good
+signals and up to an hour when buried in noise, and the second sync
+alarm has not been raised for two minutes, the clock is set (or
+verified) and is selectable to discipline the system clock.</p>
+
+<p>As long as the clock is set or verified, the system clock
+offsets are provided once each second to the reference clock
+interface, where they are saved in a buffer. At the end of each
+minute, the buffer samples are groomed by the median filter and
+trimmed-mean averaging functions. Using these functions, the system
+clock can in principle be disciplined to a much finer resolution
+than the 125-<font face="Symbol">m</font>s sample interval would
+suggest, although the ultimate accuracy is probably limited by
+propagation delay variations as the ionspheric height varies
+throughout the day and night.</p>
+
+<p>As long as signals are available, the clock frequency is
+disciplined for use during times when the signals are unavailable.
+The algorithm refines the frequency offset using increasingly
+longer averaging intervals to 1024 s, where the precision is about
+0.1 PPM. With good signals, it takes well over two hours to reach
+this degree of precision; however, it can take many more hours than
+this in case of marginal signals. Once reaching the limit, the
+algorithm will follow frequency variations due to temperature
+fluctuations and ionospheric height variations.</p>
+
+<p>It 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 is first started, the NTP reference identifier appears as
+<tt>NONE</tt>. When the driver has acquired one or both stations
+and mitigated which one is best, it sets the station identifier in
+the timecode as described below. In addition, the NTP reference
+identifier is set to the station callsign. If the propagation
+delays has 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 will be seamless.</p>
<p>Once the clock has been set for the first time, it will appear
-reachable and selectable to discipline the system clock, even if the
-broadcast signal fades to obscurity. A consequence of this design is
-that, once the clock is set, the time and frequency are disciplined only
-by the second sync pulse and the clock digits themselves are driven by
-the clock state machine and ordinarily never changed. However, as long
-as the clock is set correctly, it will continue to read correctly after
-a period of signal loss, as long as it does not drift more than 500 ms
-from the correct time. Assuming the clock frequency can be disciplined
-within 1 PPM, the clock could coast without signals for some 5.8 days
-without exceeding that limit. If for some reason this did happen, the
-clock would be in the wrong second and would never resynchronize. To
-protect against this most unlikely situation, if after four days with no
-signals, the clock is considered unset and resumes the synchronization
-procedure from the beginning.
-
-<p>To work well, the driver needs a communications receiver with good
-audio response at 100 Hz. Most shortwave and communications receivers
-roll off the audio response below 250 Hz, so this can be a problem,
-especially with receivers using DSP technology, since DSP filters can
-have very fast rolloff outside the passband. Some DSP transceivers, in
-particular the ICOM 775, have a programmable low frequency cutoff which
-can be set as low as 80 Hz. However, this particular radio has a strong
-low frequency buzz at about 10 Hz which appears in the audio output and
-can affect data recovery under marginal conditions. Although not tested,
-it would seem very likely that a cheap shortwave receiver could function
-just as well as an expensive communications receiver.
+reachable and selectable to discipline the system clock, even if
+the broadcast signal fades to obscurity. A consequence of this
+design is that, once the clock is set, the time and frequency are
+disciplined only by the second sync pulse and the clock digits
+themselves are driven by the clock state machine and ordinarily
+never changed. However, as long as the clock is set correctly, it
+will continue to read correctly after a period of signal loss, as
+long as it does not drift more than 500 ms from the correct time.
+Assuming the clock frequency can be disciplined within 1 PPM, the
+clock could coast without signals for some 5.8 days without
+exceeding that limit. If for some reason this did happen, the clock
+would be in the wrong second and would never resynchronize. To
+protect against this most unlikely situation, if after four days
+with no signals, the clock is considered unset and resumes the
+synchronization procedure from the beginning.</p>
+
+<p>To work well, the driver needs a communications receiver with
+good audio response at 100 Hz. Most shortwave and communications
+receivers roll off the audio response below 250 Hz, so this can be
+a problem, especially with receivers using DSP technology, since
+DSP filters can have very fast rolloff outside the passband. Some
+DSP transceivers, in particular the ICOM 775, have a programmable
+low frequency cutoff which can be set as low as 80 Hz. However,
+this particular radio has a strong low frequency buzz at about 10
+Hz which appears in the audio output and can affect data recovery
+under marginal conditions. Although not tested, it would seem very
+likely that a cheap shortwave receiver could function just as well
+as an expensive communications receiver.</p>
<h4>Autotune</h4>
-<p>The driver includes provisions to automatically tune the radio in
-response to changing radio propagation conditions throughout the day and
-night. The radio interface is compatible with the ICOM CI-V standard,
-which is a bidirectional serial bus operating at TTL levels. The bus can
-be connected to a serial port using a level converter such as the CT-17.
-The serial port speed is presently compiled in the program, but can be
-changed in the driver source file.
-
-<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually
-expressed in hex format. To activate the CI-V interface, the
-<tt>mode</tt> keyword of the <tt>server</tt> configuration command
-specifies a nonzero select code in decimal format. A table of ID select
-codes for the known ICOM radios is given below. Since all ICOM select
-codes are less than 128, the high order bit of the code is used by the
-driver to specify the baud rate. If this bit is not set, the rate is
-9600 bps for the newer radios; if set, the rate is 1200 bps for the
-older radios. A missing <tt>mode</tt> keyword or a zero argument leaves
-the interface disabled.
-
-<p>If specified, the driver will attempt to open the device
-<tt>/dev/icom</tt> and, if successful will activate the autotune
-function and tune the radio to each operating frequency in turn while
-attempting to acquire minute sync from either WWV or WWVH. However, the
-driver is liberal in what it assumes of the configuration. If the
-<tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus
-or radio is inoperative, the driver quietly gives up with no harm done.
-
-<p>Once acquiring minute sync, 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
-sync pulse and data pulse amplitudes and SNR and update the compare
-counter. 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 rotation, 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>Reception conditions for each frequency and station are evaluated
-according to a metric which considers the minute sync pulse amplitude,
-SNR and jitter, as well as, the data pulse amplitude and SNR. The minute
-pulse is evaluated at second 0, while the data pulses are evaluated at
-seconds 59 and 1. The results are summarized in a scoreboard of three
-bits
+<p>The driver includes provisions to automatically tune the radio
+in response to changing radio propagation conditions throughout the
+day and night. The radio interface is compatible with the ICOM CI-V
+standard, which is a bidirectional serial bus operating at TTL
+levels. The bus can be connected to a serial port using a level
+converter such as the CT-17. The serial port speed is presently
+compiled in the program, but can be changed in the driver source
+file.</p>
+
+<p>Each ICOM radio is assigned a unique 8-bit ID select code,
+usually expressed in hex format. To activate the CI-V interface,
+the <tt>mode</tt> keyword of the <tt>server</tt> configuration
+command specifies a nonzero select code in decimal format. A table
+of ID select codes for the known ICOM radios is given below. Since
+all ICOM select codes are less than 128, the high order bit of the
+code is used by the driver to specify the baud rate. If this bit is
+not set, the rate is 9600 bps for the newer radios; if set, the
+rate is 1200 bps for the older radios. A missing <tt>mode</tt>
+keyword or a zero argument leaves the interface disabled.</p>
+
+<p>If specified, the driver will attempt to open the device <tt>
+/dev/icom</tt> and, if successful will activate the autotune
+function and tune the radio to each operating frequency in turn
+while attempting to acquire minute sync from either WWV or WWVH.
+However, the driver is liberal in what it assumes of the
+configuration. If the <tt>/dev/icom</tt> link is not present or the
+open fails or the CI-V bus or radio is inoperative, the driver
+quietly gives up with no harm done.</p>
+
+<p>Once acquiring minute sync, 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 sync pulse and data pulse amplitudes and SNR and
+update the compare counter. 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 rotation, 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>Reception conditions for each frequency and station are
+evaluated according to a metric which considers the minute sync
+pulse amplitude, SNR and jitter, as well as, the data pulse
+amplitude and SNR. The minute pulse is evaluated at second 0, while
+the data pulses are evaluated at seconds 59 and 1. The results are
+summarized in a scoreboard of three bits</p>
<dl>
+<dt><tt>0x0001</tt></dt>
-<p><dt><tt>0x0001</tt>
-<dd>Jitter exceeded. The difference in epoches between the last minute
-sync pulse and the current one exceeds 50 ms (400 samples).</dd>
+<dd>Jitter exceeded. The difference in epoches between the last
+minute sync pulse and the current one exceeds 50 ms (400
+samples).</dd>
-<dt><tt>0x0002</tt>
-<dd>Minute pulse error. For the minute sync pulse in second 0, either
-the amplitude or SNR is below threshold (2000 and 20 dB,
-respectively).</dd>
+<dt><tt>0x0002</tt></dt>
-<dt><tt>0x0004</tt>
-<dd>Minute pulse error. For both of the data pulses in seocnds 59 and 1,
-either the amplitude or SNR is below threshold (1000 and 10 dB,
+<dd>Minute pulse error. For the minute sync pulse in second 0,
+either the amplitude or SNR is below threshold (2000 and 20 dB,
respectively).</dd>
+<dt><tt>0x0004</tt></dt>
+
+<dd>Minute pulse error. For both of the data pulses in seocnds 59
+and 1, either the amplitude or SNR is below threshold (1000 and 10
+dB, respectively).</dd>
</dl>
<p>If none of the scoreboard bits are set, the compare counter is
-increased by one to a maximum of six. If any bits are set, the counter
-is decreased by one to a minimum of zero. At the end of each minute, the
-frequency and station with the maximum compare count is chosen, with
-ties going to the highest frequency.
+increased by one to a maximum of six. If any bits are set, the
+counter is decreased by one to a minimum of zero. At the end of
+each minute, the frequency and station with the maximum compare
+count is chosen, with ties going to the highest frequency.</p>
<h4>Diagnostics</h4>
-<p>The autotune process produces diagnostic information along with the
-timecode. This is very useful for evaluating the performance of the
-algorithm, as well as radio propagation conditions in general. The
-message is produced once each minute for each frequency in turn after
-minute sync has been acquired.
+<p>The autotune process produces diagnostic information along with
+the timecode. This is very useful for evaluating the performance of
+the algorithm, as well as radio propagation conditions in general.
+The message is produced once each minute for each frequency in turn
+after minute sync has been acquired.</p>
-<p><tt>wwv5 port agc wwv wwvh</tt>
+<p><tt>wwv5 port agc wwv wwvh</tt></p>
-<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain,
-respectively, for this frequency 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>where <tt>port</tt> and <tt>agc</tt> are the audio port and
+gain, respectively, for this frequency 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 comp sync/snr/jitr</tt>
+<p><tt>ident score comp sync/snr/jitr</tt></p>
<p>where <tt>ident</tt>encodes the station (<tt>C</tt> for WWV,
-<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20), <tt>score</tt>
-is the scoreboard described above, <tt>comp</tt> is the compare counter,
-<tt>sync</tt> is the minute sync pulse amplitude, <tt>snr</tt> the SNR
-of the pulse and <tt>jitr</tt> is the sample difference between the
-current epoch and the last epoch. An example is:
+<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20), <tt>
+score</tt> is the scoreboard described above, <tt>comp</tt> is the
+compare counter, <tt>sync</tt> is the minute sync pulse amplitude,
+<tt>snr</tt> the SNR of the pulse and <tt>jitr</tt> is the sample
+difference between the current epoch and the last epoch. An example
+is:</p>
-<p><tt>wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</tt>
+<p><tt>wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0
+22/-12.4/8846</tt></p>
<p>Here the radio is tuned to 20 MHz and the line-in port AGC is
-currently 111 at that frequency. The message contains a report for WWV
-(<tt>C20</tt>) and WWVH (<tt>H20</tt>). The WWV report scoreboard is
-0100 and the compare count is 6, which suggests very good reception
-conditions, and the minute sync amplitude and SNR are well above
-thresholds (2000 and 20 dB, respectively). Probably the most sensitive
-indicator of reception quality is the jitter, -3 samples, which is well
-below threshold (50 ms or 400 samples). While the message shows solid
-reception conditions from WWV, this is not the case for WWVH. Both the
-minute sync amplitude and SNR are below thresholds and the jitter is
-above threshold.
-
-<p>A sequence of five messages, one for each minute, might appear as
-follows:
-
-<p><pre>wwv5 2 95 C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754
+currently 111 at that frequency. The message contains a report for
+WWV (<tt>C20</tt>) and WWVH (<tt>H20</tt>). The WWV report
+scoreboard is 0100 and the compare count is 6, which suggests very
+good reception conditions, and the minute sync amplitude and SNR
+are well above thresholds (2000 and 20 dB, respectively). Probably
+the most sensitive indicator of reception quality is the jitter, -3
+samples, which is well below threshold (50 ms or 400 samples).
+While the message shows solid reception conditions from WWV, this
+is not the case for WWVH. Both the minute sync amplitude and SNR
+are below thresholds and the jitter is above threshold.</p>
+
+<p>A sequence of five messages, one for each minute, might appear
+as follows:</p>
+
+<pre>
+wwv5 2 95 C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754
wwv5 2 99 C5 0104 0 3995/21.8/395 H5 0207 0 27/-9.3/18826
wwv5 2 239 C10 0105 0 9994/30.0/2663 H10 0207 0 54/-16.1/-529
wwv5 2 155 C15 0103 3 3300/17.8/-1962 H15 0203 0 236/17.0/4873
-wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</pre>
+wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846
+</pre>
-<p>Clearly, the only frequencies that are available are 15 MHz and 20
-MHz and propagation may be failing for 15 MHz. However, minute sync
-pulses are being heard on 5 and 10 MHz, even though the data pulses are
-not. This is typical of late afternoon when the maximum usable frequency
-(MUF) is falling and the ionospheric loss at the lower frequencies is
-beginning to decrease.
+<p>Clearly, the only frequencies that are available are 15 MHz and
+20 MHz and propagation may be failing for 15 MHz. However, minute
+sync pulses are being heard on 5 and 10 MHz, even though the data
+pulses are not. This is typical of late afternoon when the maximum
+usable frequency (MUF) is falling and the ionospheric loss at the
+lower frequencies is beginning to decrease.</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 discipline 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>chu</tt> for convenient filtering with the Unix <tt>grep</tt>
-command.
+<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 discipline 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>chu</tt> for convenient
+filtering with the Unix <tt>grep</tt> command.</p>
<p>In the following descriptions the units of amplitude, phase,
probability and likelihood are normalized to the range 0-6000 for
-convenience. In addition, the signal/noise ratio (SNR) and likelihood
-ratio are measured in decibels and the words with bit fields are in
-hex. Most messages begin with a leader in the following format:
+convenience. In addition, the signal/noise ratio (SNR) and
+likelihood ratio are measured in decibels and the words with bit
+fields are in hex. Most messages begin with a leader in the
+following format:</p>
-<p><tt>wwvn ss stat sigl</tt>
+<p><tt>wwvn ss stat sigl</tt></p>
-<p>where <tt>wwvn</tt> is the message code, <tt>ss</tt> the second of
-minute, <tt>stat</tt> the driver status word and <tt>sigl</tt> the
-second sync pulse amplitude. A full explanation of the status bits is
-contained in the driver source listing; however, the following are the
-most useful for debugging.
+<p>where <tt>wwvn</tt> is the message code, <tt>ss</tt> the second
+of minute, <tt>stat</tt> the driver status word and <tt>sigl</tt>
+the second sync pulse amplitude. A full explanation of the status
+bits is contained in the driver source listing; however, the
+following are the most useful for debugging.</p>
<dl>
+<dt><tt>0x0001</tt></dt>
-<p><dt><tt>0x0001</tt>
<dd>Minute sync. Set when the decoder has identified a station and
acquired the minute sync pulse.</dd>
-<p><dt><tt>0x0002</tt>
-<dd>Second sync. Set when the decoder has acquired the second sync pulse
-and within 125 <font face=Symbol>m</font>s of the correct phase.</dd>
-<p><dt><tt>0x0004</tt>
-<dd>Minute unit sync. Set when the decoder has reliably determined the
-unit digit of the minute.</dd>
+<dt><tt>0x0002</tt></dt>
+
+<dd>Second sync. Set when the decoder has acquired the second sync
+pulse and within 125 <font face="Symbol">m</font>s of the correct
+phase.</dd>
-<p><dt><tt>0x0008</tt>
-<dd>Clock set. Set when the decoder has reliably determined all nine
-digits of the timecode and is selectable to discipline the system
-clock.</dd>
+<dt><tt>0x0004</tt></dt>
+<dd>Minute unit sync. Set when the decoder has reliably determined
+the unit digit of the minute.</dd>
+
+<dt><tt>0x0008</tt></dt>
+
+<dd>Clock set. Set when the decoder has reliably determined all
+nine digits of the timecode and is selectable to discipline the
+system clock.</dd>
</dl>
-<p>With debugging enabled the driver produces messages in the following
-formats:
+<p>With debugging enabled the driver produces messages in the
+following formats:</p>
-<p>Format <tt>wwv8</tt> messages are produced once per minute by the WWV
-and WWVH station processes before minute sync has been acquired. They
-show the progress of identifying and tracking the minute pulse of each
-station.
+<p>Format <tt>wwv8</tt> messages are produced once per minute by
+the WWV and WWVH station processes before minute sync has been
+acquired. They show the progress of identifying and tracking the
+minute pulse of each station.</p>
-<p><tt>wwv8 port agc ident comp ampl snr epoch jitr offs</tt>
+<p><tt>wwv8 port agc ident comp ampl snr epoch jitr offs</tt></p>
-<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain,
-respectively. The <tt>ident</tt>encodes the station (<tt>C</tt> for WWV,
-<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20). For the
-encoded frequency, <tt>comp</tt> is the compare counter, <tt>ampl</tt>
-the pulse amplitude, <tt>snr</tt> the SNR, <tt>epoch</tt> the sample
-number of the minute pulse in the minute, <tt>jitr</tt> the change since
-the last <tt>epoch</tt> and <tt>offs</tt> the minute pulse offset
-relative to the second pulse. An example is:
+<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and
+gain, respectively. The <tt>ident</tt>encodes the station
+(<tt>C</tt> for WWV, <tt>H</tt> for WWVH) and frequency (2, 5, 10,
+15 and 20). For the encoded frequency, <tt>comp</tt> is the compare
+counter, <tt>ampl</tt> the pulse amplitude, <tt>snr</tt> the SNR,
+<tt>epoch</tt> the sample number of the minute pulse in the minute,
+<tt>jitr</tt> the change since the last <tt>epoch</tt> and <tt>
+offs</tt> the minute pulse offset relative to the second pulse. An
+example is:</p>
-<p><tt> wwv8 2 127 C15 2 9247 30.0 18843 -1 1</tt>
-<br><tt>wwv8 2 127 H15 0 134 -2.9 19016 193 174</tt>
+<p><tt>wwv8 2 127 C15 2 9247 30.0 18843 -1 1</tt><br>
+<tt>wwv8 2 127 H15 0 134 -2.9 19016 193 174</tt></p>
<p>Here the radio is tuned to 15 MHz and the line-in port AGC is
-currently 127 at that frequency. The driver has not yet acquired minute
-sync, WWV has been heard for at least two minutes, and WWVH is in the
-noise. The WWV minute pulse amplitude and SNR are well above the
-threshold (2000 and 6 dB, respectively) and the minute epoch has been
-determined -1 sample relative to the last one and 1 sample relative to
-the second sync pulse. The compare counter has incrmented to two; when
-it gets to three, minute sync has been acquired.
+currently 127 at that frequency. The driver has not yet acquired
+minute sync, WWV has been heard for at least two minutes, and WWVH
+is in the noise. The WWV minute pulse amplitude and SNR are well
+above the threshold (2000 and 6 dB, respectively) and the minute
+epoch has been determined -1 sample relative to the last one and 1
+sample relative to the second sync pulse. The compare counter has
+incrmented to two; when it gets to three, minute sync has been
+acquired.</p>
+
+<p>Format <tt>wwv3</tt> messages are produced after minute sync has
+been acquired and until the seconds unit digit is determined. They
+show the results of decoding each bit of the transmitted
+timecode.</p>
+
+<p><tt>wwv3 ss stat sigl ampl phas snr prob like</tt></p>
-<p>Format <tt>wwv3</tt> messages are produced after minute sync has been
-acquired and until the seconds unit digit is determined. They show the
-results of decoding each bit of the transmitted timecode.
+<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
+<tt>ampl</tt> is the subcarrier amplitude, <tt>phas</tt> the
+subcarrier phase, <tt>snr</tt> the subcarrier SNR, <tt>prob</tt>
+the bit probability and <tt>like</tt> the bit likelihood. An
+example is:</p>
-<p><tt>wwv3 ss stat sigl ampl phas snr prob like</tt>
+<p><tt>wwv3 28 0123 4122 4286 0 24.8 -5545 -1735</tt></p>
-<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
-<tt>ampl</tt> is the subcarrier amplitude, <tt>phas</tt> the subcarrier
-phase, <tt>snr</tt> the subcarrier SNR, <tt>prob</tt> the bit
-probability and <tt>like</tt> the bit likelihood. An example is:
-
-<p><tt>wwv3 28 0123 4122 4286 0 24.8 -5545 -1735</tt>
-
-<p>Here the driver has acquired minute and second sync, but has not yet
-determined the seconds unit digit. However, it has just decoded bit 28
-of the minute. The results show the second sync pulse amplitude well
-over the threshold (500), subcarrier amplitude well above the threshold
-(1000), good subcarrier tracking phase and SNR well above the threshold
-(10 dB). The bit is almost certainly a zero and the likelihood of a zero
-in this second is very high.
-<p>Format <tt>wwv4</tt> messages are produced for each of the nine BCD
-timecode digits until the clock has been set or verified. They show the
-results of decoding each digit of the transmitted timecode.
-<p><tt>wwv4 ss stat sigl radx ckdig mldig diff cnt like snr</tt>
+<p>Here the driver has acquired minute and second sync, but has not
+yet determined the seconds unit digit. However, it has just decoded
+bit 28 of the minute. The results show the second sync pulse
+amplitude well over the threshold (500), subcarrier amplitude well
+above the threshold (1000), good subcarrier tracking phase and SNR
+well above the threshold (10 dB). The bit is almost certainly a
+zero and the likelihood of a zero in this second is very high.</p>
+
+<p>Format <tt>wwv4</tt> messages are produced for each of the nine
+BCD timecode digits until the clock has been set or verified. They
+show the results of decoding each digit of the transmitted
+timecode.</p>
+
+<p><tt>wwv4 ss stat sigl radx ckdig mldig diff cnt like
+snr</tt></p>
<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
<tt>radx</tt> is the digit radix (3, 4, 6, 10), <tt>ckdig</tt> the
current clock digit, <tt>mldig</tt> the maximum likelihood digit,
-<tt>diff</tt> the difference between these two digits modulo the radix,
-<tt>cnt</tt> the compare counter, <tt>like</tt> the digit likelihood and
-<tt>snr</tt> the likelihood ratio. An example is:
+<tt>diff</tt> the difference between these two digits modulo the
+radix, <tt>cnt</tt> the compare counter, <tt>like</tt> the digit
+likelihood and <tt>snr</tt> the likelihood ratio. An example
+is:</p>
-<p><tt>wwv4 8 010f 5772 10 9 9 0 6 4615 6.1</tt>
+<p><tt>wwv4 8 010f 5772 10 9 9 0 6 4615 6.1</tt></p>
-<p>Here the driver has previousl set or verified the clock. It has just
-decoded the digit preceding second 8 of the minute. The digit radix is
-10, the current clock and maximum likelihood digits are both 9, the
-likelihood is well above the threshold (1000) and the likelihood
-function well above threshold (3.0 dB). Short of a hugely unlikely
-probability conspiracy, the clock digit is most certainly a 9.
+<p>Here the driver has previousl set or verified the clock. It has
+just decoded the digit preceding second 8 of the minute. The digit
+radix is 10, the current clock and maximum likelihood digits are
+both 9, the likelihood is well above the threshold (1000) and the
+likelihood function well above threshold (3.0 dB). Short of a
+hugely unlikely probability conspiracy, the clock digit is most
+certainly a 9.</p>
-<p>Format <tt>wwv2</tt> messages are produced at each master oscillator
-frequency update, which starts at 8 s, but eventually climbs to 1024 s.
-They show the progress of the algorithm as it refines the frequency
-measurement to a precision of 0.1 PPM.
+<p>Format <tt>wwv2</tt> messages are produced at each master
+oscillator frequency update, which starts at 8 s, but eventually
+climbs to 1024 s. They show the progress of the algorithm as it
+refines the frequency measurement to a precision of 0.1 PPM.</p>
-<p><tt>wwv2 ss stat sigl avint avcnt avinc jitr delt freq</tt>
+<p><tt>wwv2 ss stat sigl avint avcnt avinc jitr delt freq</tt></p>
<p>where <tt>ss</tt>, <tt>stat</tt> and <tt>sigl</tt> are as above,
-<tt>avint</tt> is the averaging interval, <tt>avcnt</tt> the averaging
-interval counter, <tt>avinc</tt> the interval increment, <tt>jitr</tt>
-the sample change between the beginning and end of the interval,
-<tt>delt</tt> the computed frequency change and <tt>freq</tt> the
-current frequency (PPM). An example is:
+<tt>avint</tt> is the averaging interval, <tt>avcnt</tt> the
+averaging interval counter, <tt>avinc</tt> the interval increment,
+<tt>jitr</tt> the sample change between the beginning and end of
+the interval, <tt>delt</tt> the computed frequency change and <tt>
+freq</tt> the current frequency (PPM). An example is:</p>
-<p><tt>wwv2 22 030f 5795 256 256 4 0 0.0 66.7</tt>
+<p><tt>wwv2 22 030f 5795 256 256 4 0 0.0 66.7</tt></p>
<p>Here the driver has acquired minute and second sync and set the
-clock. The averaging interval has increased to 256 s on the way to 1024
-s, has stayed at that interval for 4 averaging intervals, has measured
-no change in frequency and the current frequency is 66.7 PPM.
+clock. The averaging interval has increased to 256 s on the way to
+1024 s, has stayed at that interval for 4 averaging intervals, has
+measured no change in frequency and the current frequency is 66.7
+PPM.</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.
+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:
+When enabled by the <tt>filegen</tt> facility, every received
+timecode is written to the <tt>clockstats</tt> file in the
+following format:
<pre>
sq yy ddd hh:mm:ss.fff ld du lset agc stn rfrq errs freq cons
avgt averaging time
</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
+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.
+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 all nine digits of the timecode are
+correctly set.</dd>
-<dt><tt>s</tt>
-<dd>The sync indicator is initially <tt>?</tt> before the clock is set,
-but turns to space when all nine digits of the timecode are correctly
-set.</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:
-<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></dt>
+
+<dd>Sync alarm. The decoder may not be in correct second or minute
+phase relative to the transmitter.</dd>
-<dt><tt>0x8</tt>
-<dd>Sync alarm. The decoder may not be in correct second or minute phase
-relative to the transmitter.</dd>
+<dt><tt>0x4</tt></dt>
-<dt><tt>0x4</tt>
<dd>Error alarm. More than 30 data bit errors occurred in the last
minute.</dd>
-<dt><tt>0x2</tt>
-<dd>Symbol alarm. The probability of correct decoding for a digit or
-miscellaneous bit has fallen below the threshold.</dd>
+<dt><tt>0x2</tt></dt>
-<dt><tt>0x1</tt>
-<dd>Decoding alarm. A maximum likelihood digit fails to agree with the
-current associated clock digit.</dd>
+<dd>Symbol alarm. The probability of correct decoding for a digit
+or miscellaneous bit has fallen below the threshold.</dd>
+<dt><tt>0x1</tt></dt>
+
+<dd>Decoding alarm. A maximum likelihood digit fails to agree with
+the current associated clock digit.</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 condition that may in future result in an error.
+It is important to note that one or more of the above alarms does
+not necessarily indicate a clock error, but only that the decoder
+has detected a condition that may in future result in an
+error.</dd>
+
+<dt><tt>yyyy ddd hh:mm:ss.fff</tt></dt>
-<dt><tt>yyyy ddd hh:mm:ss.fff</tt></tt>
-<dd>The timecode format itself is self explanatory. Since the driver
-latches the on-time epoch directly from the second sync pulse, the
-fraction <tt>fff</tt>is always zero. Although the transmitted timecode
-includes only the year of century, the Gregorian year is augmented 2000
-if the indicated year is less than 72 and 1900 otherwise.</dd>
+<dd>The timecode format itself is self explanatory. Since the
+driver latches the on-time epoch directly from the second sync
+pulse, the fraction <tt>fff</tt>is always zero. Although the
+transmitted timecode includes only the year of century, the
+Gregorian year is augmented 2000 if the indicated year is less than
+72 and 1900 otherwise.</dd>
-<dt><tt>l</tt>
-<dd>The leap second warning is normally space, but changes to <tt>L</tt>
-if a leap second is to occur at the end of the month of June or
-December.</dd>
+<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 of June
+or December.</dd>
+
+<dt><tt>d</tt></dt>
-<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.</dd>
-<dt><tt>dut</tt>
-<dd>The DUT sign and magnitude shows the current UT1 offset relative to
-the displayed UTC time, in deciseconds.</dd>
-
-<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 time was last verified relative to the
-broadcast signal.</dd>
-
-<dt><tt>agc</tt>
-<dd>The audio gain shows the current codec gain setting in the range 0
-to 255. Ordinarily, the receiver audio gain control or IRIG level
-control should be set for a value midway in this range.
-
-<dt><tt>ident</tt>
+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>dut</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 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 or IRIG
+level 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>C</tt> for WWV or
-<tt>H</tt> for WWVH, and frequency being tracked. If neither station is
-heard on any frequency, the station identifier shows <tt>X</tt>.</dd>
-
-<dt><tt>comp</tt>
-<dd>The minute sync compare counter is useful to determine the quality
-of the minute sync signal and can range from 0 (no signal) to 5
-(best).</dd>
-
-<dt><tt>errs</tt>
-<dd>The bit error counter is useful to determine the quality of the data
-signal received in the most recent minute. It is normal to drop a couple
-of data bits under good signal conditions and increasing numbers as
-conditions worsen. While the decoder performs moderately well even with
-half the bits are in error in any minute, usually by that point the sync
-signals are lost and the decoder reverts to free-run anyway.</dd>
-
-<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.</dd>
-
-<dt><tt>avgt</tt>
+<tt>H</tt> for WWVH, and frequency being tracked. If neither
+station is heard on any frequency, the station identifier shows
+<tt>X</tt>.</dd>
+
+<dt><tt>comp</tt></dt>
+
+<dd>The minute sync compare counter is useful to determine the
+quality of the minute sync signal and can range from 0 (no signal)
+to 5 (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 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 sync signals are lost and the decoder
+reverts to free-run anyway.</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>avgt</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>
-
+indicates the driver is operating at the best possible resolution
+in time and frequency.</dd>
</dl>
-<p>An example timecode is:
+<p>An example timecode is:</p>
-<p><tt> 0 2000 006 22:36:00.000 S +3 1 115 C20 6 5 66.4 1024</tt>
+<p><tt>0 2000 006 22:36:00.000 S +3 1 115 C20 6 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.
-Excellent reeiving conditions prevail, as indicated by the compare count
-6 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>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. Excellent reeiving conditions prevail, as
+indicated by the compare count 6 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>Modes</h4>
<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
-command specifies the ICOM ID select code. A missing or zero argument
-disables the CI-V interface. Following are the ID select codes for the
-known radios.
-<p><table cols=6 width=100%>
+command specifies the ICOM ID select code. A missing or zero
+argument disables the CI-V interface. Following are the ID select
+codes for the known radios.</p>
+<table cols="6" width="100%">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>0x1A</td>
<td>26</td>
</tr>
+
<tr>
<td>IC751</td>
<td>0x1c</td>
<td>0x34</td>
<td>52</td>
</tr>
+
<tr>
<td>IC761</td>
<td>0x1e</td>
<td>0x2a</td>
<td>42</td>
</tr>
-
</table>
<h4>Fudge Factors</h4>
<dl>
+<dt><tt>time1 <i>time</i></tt></dt>
-<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>
+<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>time2 <i>time</i></tt></dt>
-<dt><tt>stratum <I>number</I></tt></dt>
-<dd>Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</dd>
+<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>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.
<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>
+
+<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>
+
+<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>
+
<h4>Additional Information</h4>
-<A HREF="refclock.htm">Reference Clock Drivers</A>
-<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
+<a href="refclock.htm">Reference Clock Drivers</a> <br>
+<a href="audio.htm">Reference Clock Audio Drivers</a>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
-<html><head><title>
-IRIG Audio Decoder
-</title></head><body><h3>
-IRIG Audio Decoder
-</h3><hr>
-
-<H4>Synopsis</H4>
-
-Address: 127.127.6.<I>u</I>
-<BR>Reference ID: <TT>IRIG</TT>
-<BR>Driver ID: <TT>IRIG_AUDIO</TT>
-<BR>Audio Device: <TT>/dev/audio</TT> and <TT>/dev/audioctl</TT>
-
-<P>Note: This driver supersedes an older one of the same name, address
-and ID which required replacing the original kernel audio driver with
-another which works only on older Sun SPARCstation systems. The new
-driver described here uses the stock kernel audio driver and works in
-SunOS 4.1.3 and Solaris 2.6 versions and probably all versions in
-between. The new driver requires no modification of the operating
-system. While it is generic and likely portable to other systems, it is
-somewhat slower than the original, since the extensive signal
-conditioning, filtering and decoding is done in user space, not kernel
-space.
-
-<H4>Description</H4>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>IRIG Audio Decoder</title>
+</head>
+<body>
+<h3>IRIG Audio Decoder</h3>
+
+<hr>
+<h4>Synopsis</h4>
+
+Address: 127.127.6.<i>u</i> <br>
+Reference ID: <tt>IRIG</tt> <br>
+Driver ID: <tt>IRIG_AUDIO</tt> <br>
+Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
+
+<p>Note: This driver supersedes an older one of the same name,
+address and ID which required replacing the original kernel audio
+driver with another which works only on older Sun SPARCstation
+systems. The new driver described here uses the stock kernel audio
+driver and works in SunOS 4.1.3 and Solaris 2.6 versions and
+probably all versions in between. The new driver requires no
+modification of the operating system. While it is generic and
+likely portable to other systems, it is somewhat slower than the
+original, since the extensive signal conditioning, filtering and
+decoding is done in user space, not kernel space.</p>
+
+<h4>Description</h4>
This driver supports the Inter-Range Instrumentation Group (IRIG)
-standard time distribution signal using the audio codec native to some
-workstations. This signal is generated by several radio clocks,
-including those made by Arbiter, Austron, Bancomm, Odetics, Spectracom
-and TrueTime, among others, although it is often an add-on option. The
-signal is connected via an optional attenuator box and cable to either
-the microphone or line-in port. The driver receives, demodulates and
-decodes the IRIG-B and IRIG-E signal formats using internal filters
-designed to reduce the effects of noise and interference.
-
-<p>This driver incorporates several features in common with other audio
-drivers such as described in the <a href=driver7.htm>Radio CHU Audio
-Demodulator/Decoder</a> and the <a href=driver36.htm>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.htm>Reference Clock
-Audio Drivers</a> page.
-
-<P>The IRIG signal format uses an amplitude-modulated carrier with
-pulse-width modulated data bits. For IRIG-B, the carrier frequency is
-1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy is 100
-Hz and bit rate 10 b/s. While IRIG-B provides the best accuracy,
-generally within a few tens of microseconds relative to IRIG time, it
-can also generate a significant load on the processor with older
-workstations. Generally, the accuracy with IRIG-E is about ten times
-worse than IRIG-B, but the processor load is ten times less.
-
-<P>The program processes 8000-Hz mu-law companded samples using separate
-signal filters for IRIG-B and IRIG-E, a comb filter, envelope detector
-and automatic threshold corrector. Cycle crossings relative to the
-corrected slice level determine the width of each pulse and its value -
-zero, one or position identifier. The data encode 20 BCD digits which
-determine the second, minute, hour and day of the year and sometimes the
-year and synchronization condition. The comb filter exponentially
-averages the corresponding samples of successive baud intervals in order
-to reliably identify the reference carrier cycle. A type-II phase-lock
-loop (PLL) performs additional integration and interpolation to
-accurately determine the zero crossing of that cycle, which determines
-the reference timestamp. A pulse-width discriminator demodulates the
-data pulses, which are then encoded as the BCD digits of the timecode.
-The timecode and reference timestamp are updated once each second with
-IRIG-B (ten seconds with IRIG-E) and local clock offset samples saved
-for later processing. At poll intervals of 64 s, the saved samples are
-processed by a trimmed-mean filter and used to update the system clock.
-
-<P>Infinite impulse response (IIR) filters are used with both IRIG-B and
-IRIG-E formats. An 800-Hz highpass filter is used for IRIG-B and a
-130-Hz lowpass filter for IRIG-E. These are intended for use with noisy
-signals, such as might be received over a telephone line or radio
-circuit, or when interfering signals may be present in the audio
-passband. The driver determines which IRIG format is in use by sampling
-the amplitude of each filter output and selecting the one with maximum
-signal. An automatic gain control feature provides protection against
-overdriven or underdriven input signal amplitudes. It is designed to
-maintain adequate demodulator signal amplitude while avoiding occasional
-noise spikes. In order to assure reliable capture, the decompanded input
-signal amplitude must be greater than 100 units and the codec sample
-frequency error less than 250 PPM (.025 percent).
-
-<P>The program performs a number of error checks to protect against
-overdriven or underdriven input signal levels, incorrect signal format
-or improper hardware configuration. Specifically, if any of the
-following errors occur for a timecode, the data are rejected.
+standard time distribution signal using the audio codec native to
+some workstations. This signal is generated by several radio
+clocks, including those made by Arbiter, Austron, Bancomm, Odetics,
+Spectracom and TrueTime, among others, although it is often an
+add-on option. The signal is connected via an optional attenuator
+box and cable to either the microphone or line-in port. The driver
+receives, demodulates and decodes the IRIG-B and IRIG-E signal
+formats using internal filters designed to reduce the effects of
+noise and interference.
+
+<p>This driver incorporates several features in common with other
+audio drivers such as described in the <a href="driver7.htm">Radio
+CHU Audio Demodulator/Decoder</a> and the <a href="driver36.htm">
+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.htm">Reference Clock Audio Drivers</a>
+page.</p>
+
+<p>The IRIG signal format uses an amplitude-modulated carrier with
+pulse-width modulated data bits. For IRIG-B, the carrier frequency
+is 1000 Hz and bit rate 100 b/s; for IRIG-E, the carrier frequenchy
+is 100 Hz and bit rate 10 b/s. While IRIG-B provides the best
+accuracy, generally within a few tens of microseconds relative to
+IRIG time, it can also generate a significant load on the processor
+with older workstations. Generally, the accuracy with IRIG-E is
+about ten times worse than IRIG-B, but the processor load is ten
+times less.</p>
+
+<p>The program processes 8000-Hz mu-law companded samples using
+separate signal filters for IRIG-B and IRIG-E, a comb filter,
+envelope detector and automatic threshold corrector. Cycle
+crossings relative to the corrected slice level determine the width
+of each pulse and its value - zero, one or position identifier. The
+data encode 20 BCD digits which determine the second, minute, hour
+and day of the year and sometimes the year and synchronization
+condition. The comb filter exponentially averages the corresponding
+samples of successive baud intervals in order to reliably identify
+the reference carrier cycle. A type-II phase-lock loop (PLL)
+performs additional integration and interpolation to accurately
+determine the zero crossing of that cycle, which determines the
+reference timestamp. A pulse-width discriminator demodulates the
+data pulses, which are then encoded as the BCD digits of the
+timecode. The timecode and reference timestamp are updated once
+each second with IRIG-B (ten seconds with IRIG-E) and local clock
+offset samples saved for later processing. At poll intervals of 64
+s, the saved samples are processed by a trimmed-mean filter and
+used to update the system clock.</p>
+
+<p>Infinite impulse response (IIR) filters are used with both
+IRIG-B and IRIG-E formats. An 800-Hz highpass filter is used for
+IRIG-B and a 130-Hz lowpass filter for IRIG-E. These are intended
+for use with noisy signals, such as might be received over a
+telephone line or radio circuit, or when interfering signals may be
+present in the audio passband. The driver determines which IRIG
+format is in use by sampling the amplitude of each filter output
+and selecting the one with maximum signal. An automatic gain
+control feature provides protection against overdriven or
+underdriven input signal amplitudes. It is designed to maintain
+adequate demodulator signal amplitude while avoiding occasional
+noise spikes. In order to assure reliable capture, the decompanded
+input signal amplitude must be greater than 100 units and the codec
+sample frequency error less than 250 PPM (.025 percent).</p>
+
+<p>The program performs a number of error checks to protect against
+overdriven or underdriven input signal levels, incorrect signal
+format or improper hardware configuration. Specifically, if any of
+the following errors occur for a timecode, the data are rejected.
Secifically, if any of the following errors occur for a time
-measurement, the data are rejected.
+measurement, the data are rejected.</p>
-<OL>
+<ol>
+<li>The peak carrier amplitude is less than 100 units. This usually
+means dead IRIG signal source, broken cable or wrong input
+port.</li>
-<LI>The peak carrier amplitude is less than 100 units. This usually
-means dead IRIG signal source, broken cable or wrong input port.</LI>
+<li>The frequency error is greater than ±250 PPM (.025
+percent). This usually means broken codec hardware or wrong codec
+configuration.</li>
-<LI>The frequency error is greater than ±250 PPM (.025 percent).
-This usually means broken codec hardware or wrong codec
-configuration.</LI>
+<li>The modulation index is less than 0.5. This usually means
+overdriven IRIG signal or wrong IRIG format.</li>
-<LI>The modulation index is less than 0.5. This usually means overdriven
-IRIG signal or wrong IRIG format.</LI>
+<li>A frame synchronization error has occured. This usually means
+wrong IRIG signal format or the IRIG signal source has lost
+synchronization (signature control).</li>
-<LI>A frame synchronization error has occured. This usually means wrong
-IRIG signal format or the IRIG signal source has lost synchronization
-(signature control).</LI>
+<li>A data decoding error has occured. This usually means wrong
+IRIG signal format.</li>
-<LI>A data decoding error has occured. This usually means wrong IRIG
-signal format.</LI>
+<li>The current second of the day is not exactly one greater than
+the previous one. This usually means a very noisy IRIG signal or
+insufficient CPU resources.</li>
-<LI>The current second of the day is not exactly one greater than the
-previous one. This usually means a very noisy IRIG signal or
-insufficient CPU resources.</LI>
+<li>An audio codec error (overrun) occured. This usually means
+insufficient CPU resources, as sometimes happens with Sun SPARC
+IPCs when doing something useful.</li>
+</ol>
-<LI>An audio codec error (overrun) occured. This usually means
-insufficient CPU resources, as sometimes happens with Sun SPARC IPCs
-when doing something useful.</LI>
+Note that additional checks are done elsewhere in the reference
+clock interface routines.
-</OL>
+<p>Unlike other drivers, which can have multiple instantiations,
+this one supports only one. It does not seem likely that more than
+one audio codec would be useful in a single machine. More than one
+would probably chew up too much CPU time anyway.</p>
-Note that additional checks are done elsewhere in the reference clock
-interface routines.
+<h4>IRIG-B Timecode Format</h4>
-<P>Unlike other drivers, which can have multiple instantiations, this
-one supports only one. It does not seem likely that more than one audio
-codec would be useful in a single machine. More than one would probably
-chew up too much CPU time anyway.
+The 100 elements of the IRIG timecode are numbered from 0 through
+99. Position identifiers occur at elements 0, 9, 19 and every ten
+thereafter to 99. The control function (CF) elements begin at
+element 50 (CF 1) and extend to element 78 (CF 27). The
+straight-binary-seconds (SBS) field, which encodes the seconds of
+the UTC day, begins at element 80 (CF 28) and extends to element 97
+(CF 44). The encoding of elements 50 (CF 1) through 78 (CF 27) is
+device dependent. This driver presently decodes the CF elements,
+but does nothing with them.
-<H4>IRIG-B Timecode Format</H4>
-The 100 elements of the IRIG timecode are numbered from 0 through 99.
-Position identifiers occur at elements 0, 9, 19 and every ten thereafter
-to 99. The control function (CF) elements begin at element 50 (CF 1) and
-extend to element 78 (CF 27). The straight-binary-seconds (SBS) field,
-which encodes the seconds of the UTC day, begins at element 80 (CF 28)
-and extends to element 97 (CF 44). The encoding of elements 50 (CF 1)
-through 78 (CF 27) is device dependent. This driver presently decodes
-the CF elements, but does nothing with them.
-
-<P>Where feasible, the IRIG signal source should be operated with
+<p>Where feasible, the IRIG signal source should be operated with
signature control so that, if the signal is lost or mutilated, the
source produces an unmodulated signal, rather than possibly random
-digits. The driver will automatically reject the data and declare itself
-unsynchronized in this case. Some devices, in particular Spectracom
-radio/satellite clocks, provide additional year and status indication in
-the format:
+digits. The driver will automatically reject the data and declare
+itself unsynchronized in this case. Some devices, in particular
+Spectracom radio/satellite clocks, provide additional year and
+status indication in the format:</p>
-<PRE> Element CF Function
+<pre>
+ Element CF Function
-------------------------------------
55 6 time sync status
60-63 10-13 BCD year units
65-68 15-18 BCD year tens
-</PRE>
+</pre>
+
+Other devices set these elements to zero.
+
+<h4>Performance</h4>
+
+The mu-law companded data format allows considerable latitude in
+signal levels; however, an automatic gain control (AGC) function is
+implemented to further compensate for varying input signal levels
+and to avoid signal distortion. For proper operation, the IRIG
+signal source should be configured for analog signal levels, NOT
+digital TTL levels.
+
+<p>The accuracy of the system clock synchronized to the IRIG-B
+source with this driver and the <tt>ntpd</tt> daemon is 10-20 <font
+face="symbol">m</font>s with a Sun UltraSPARC II and maybe twice
+that with a Sun SPARC IPC. The processor resources consumed by the
+daemon can be significant, ranging from about 1.2 percent on the
+faster UltraSPARC II to 38 percent on the slower SPARC IPC.
+However, the overall timing accuracy is limited by the resolution
+and stability of the CPU clock oscillator and the interval between
+clock corrections, which is 64 s with this driver. This
+performance, while probably the best that can be achieved by the
+daemon itself, can be improved with assist from the PPS discipline
+as described elsewhere in the documentation.</p>
+
+<h4>Monitor Data</h4>
+
+The timecode format used for debugging and data recording includes
+data helpful in diagnosing problems with the IRIG signal and codec
+connections. With debugging enabled (-d on the ntpd command line),
+the driver produces one line for each timecode in the following
+format:
-Other devices set these elements to zero.
+<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5
+3094572411.00027</tt></p>
-<H4>Performance</H4>
+<p>The first field containes the error flags in hex, where the hex
+bits are interpreted as below. This is followed by the IRIG status
+indicator, year of century, day of year and time of day. The status
+indicator and year are not produced by some IRIG devices. Following
+these fields are the signal amplitude (0-8100), codec gain (0-255),
+field phase (0-79), time constant (2-20), modulation index (0-1),
+carrier phase error (0±0.5) and carrier frequency error
+(PPM). The last field is the on-time timestamp in NTP format. The
+fraction part is a good indicator of how well the driver is doing.
+With an UltrSPARC 30, this is normally within a few tens of
+microseconds relative to the IRIG-B signal and within a few hundred
+microseconds with IRIG-E.</p>
-The mu-law companded data format allows considerable latitude in signal
-levels; however, an automatic gain control (AGC) function is implemented
-to further compensate for varying input signal levels and to avoid
-signal distortion. For proper operation, the IRIG signal source should
-be configured for analog signal levels, NOT digital TTL levels.
+<h4>Fudge Factors</h4>
-<P>The accuracy of the system clock synchronized to the IRIG-B source
-with this driver and the <TT>ntpd</TT> daemon is 10-20 <font
-face=symbol>m</font>s with a Sun UltraSPARC II and maybe twice that with
-a Sun SPARC IPC. The processor resources consumed by the daemon can be
-significant, ranging from about 1.2 percent on the faster UltraSPARC II
-to 38 percent on the slower SPARC IPC. However, the overall timing
-accuracy is limited by the resolution and stability of the CPU clock
-oscillator and the interval between clock corrections, which is 64 s
-with this driver. This performance, while probably the best that can be
-achieved by the daemon itself, can be improved with assist from the PPS
-discipline as described elsewhere in the documentation.
+<dl>
+<dt><tt>time1 <i>time</i></tt></dt>
-<H4>Monitor Data</H4>
+<dd>Specifies the time offset calibration factor, in seconds and
+fraction, with default 0.0.</dd>
-The timecode format used for debugging and data recording includes data
-helpful in diagnosing problems with the IRIG signal and codec
-connections. With debugging enabled (-d on the ntpd command line), the
-driver produces one line for each timecode in the following format:
+<dt><tt>time2 <i>time</i></tt></dt>
-<p><tt>00 1 98 23 19:26:52 721 143 0.694 47 20 0.083 66.5
-3094572411.00027</tt>
+<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>
-<p>The first field containes the error flags in hex, where the hex bits
-are interpreted as below. This is followed by the IRIG status indicator,
-year of century, day of year and time of day. The status indicator and
-year are not produced by some IRIG devices. Following these fields are
-the signal amplitude (0-8100), codec gain (0-255), field phase (0-79),
-time constant (2-20), modulation index (0-1), carrier phase error
-(0±0.5) and carrier frequency error (PPM). The last field is the
-on-time timestamp in NTP format. The fraction part is a good indicator
-of how well the driver is doing. With an UltrSPARC 30, this is normally
-within a few tens of microseconds relative to the IRIG-B signal and
-within a few hundred microseconds with IRIG-E.
+<dd>Specifies the driver reference identifier, an ASCII string from
+one to four characters, with default <tt>IRIG</tt>.</dd>
-<H4>Fudge Factors</H4>
+<dt><tt>flag1 0 | 1</tt></dt>
-<DL>
+<dd>Not used by this driver.</dd>
-<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>flag2 0 | 1</tt></dt>
-<DT><TT>time2 <I>time</I></TT></DT>
-<DD>Not used by this driver.</DD>
+<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>stratum <I>number</I></TT></DT>
-<DD>Specifies the driver stratum, in decimal from 0 to 15, with default
-0.</DD>
+<dt><tt>flag3 0 | 1</tt></dt>
-<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>
+<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>flag1 0 | 1</TT></DT>
-<DD>Not used by this driver.</DD>
+<dt><tt>flag4 0 | 1</tt></dt>
-<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>
+<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
+</dl>
-<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>
+<h4>Additional Information</h4>
-<DT><TT>flag4 0 | 1</TT></DT>
-<DD>Enable verbose <TT>clockstats</TT> recording if set.</DD>
-</DL>
+<a href="refclock.htm">Reference Clock Drivers</a> <br>
+<a href="audio.htm">Reference Clock Audio Drivers</a>
-<H4>Additional Information</H4>
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
-<A HREF="refclock.htm">Reference Clock Drivers</A>
-<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
-</address></a></body></html>
-<html><head><title>
-Radio CHU Audio Demodulator/Decoder
-</title></head><body><h3>
-Radio CHU Audio Demodulator/Decoder
-</h3><hr>
-
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>Radio CHU Audio Demodulator/Decoder</title>
+</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/chu_audio</tt> and <tt>/dev/audioctl</tt>
+Address: 127.127.7.<i>u</i> <br>
+Reference ID: <tt>CHU</tt> <br>
+Driver ID: <tt>CHU</tt> <br>
+Modem Port: <tt>/dev/chu<i>u</i></tt>; 300 baud, 8-bits, no parity
+<br>
+Autotune Port: <tt>/dev/icom</tt>; 1200/9600 baud, 8-bits, no
+parity <br>
+Audio Device: <tt>/dev/chu_audio</tt> and <tt>/dev/audioctl</tt>
<h4>Description</h4>
-<p>This driver synchronizes the computer time using data encoded in radio transmissions from Canadian time/frequency station CHU in Ottawa, Ontario. It replaces an earlier one, built by Dennis Ferguson in 1988, which required a special line discipline to preprocessed the signal. The new driver includes more powerful algorithms implemented directly in the driver and requires no preprocessing.
-
-<p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz and 14670 kHz in upper sideband, compatible AM mode. An ordinary shortwave receiver can be tuned manually to one of these frequencies or, in the case of ICOM receivers, the receiver can be tuned automatically as propagation conditions change throughout the day and night. The performance of this driver when tracking the station is ordinarily better than 1 ms in time with frequency drift less than 0.5 PPM when not tracking the station.
-
-<p>While there are currently no known commercial CHU receivers, a simple but effective receiver/demodulator can be constructed from an ordinary shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip, as described in the <a href=gadget.htm>Gadget Box PPS Level Converter and CHU Modem</a> page. The driver can use the modem to receive the radio signal and demodulate the data or, if available, the driver can use the audio codec of the Sun workstation or another with compatible audio interface. In the latter case, the driver implements the modem using DSP routines, so the radio can be connected directly to either the microphone on line input port.
-
-<p>This driver incorporates several features in common with other audio drivers such as described in the <a href=driver36.htm>Radio WWV/H Audio Demodulator/Decoder</a> and the <a href=driver6.htm>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.htm>Reference Clock Audio Drivers</a> page.
-
-<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h), although this can be changed with configuration commands. As long as the clock is set or verified at least once during this interval, the NTP algorithms will consider the source reachable and selectable to discipline the system clock. However, if this does not happen for eight poll intervals, the algorithms will consider the source unreachable and some other source will be chosen (if available) to discipline the system clock.
-
-<p>The decoding algorithms process the data using maximum-likelihood techniques which exploit the considerable degree of redundancy available in each broadcast message or burst. As described below, every character is sent twice and, in the case of format A bursts, the burst is sent eight times every minute. In the case of format B bursts, which are sent once each minute, the burst is considered correct only if every character matches its repetition in the burst. In the case of format A messages, a majority decoder requires at least six repetitions for each digit in the timecode and more than half of the repetitions decode to the same digit. Every character in every burst provides an independent timestamp upon arrival with a potential total of over 60 timestamps for each minute.
-
-<p>A timecode in the format described below is assembled when all bursts have been received in the minute. The timecode is considered valid and the clock set when at least one valid format B burst has been decoded and the above requirements are met. The <tt>yyyy</tt> year field in the timecode indicates whether a valid format B burst has been received. Upon startup, this field is initialized at zero; when a valid format B burst is received, it is set to the current Gregorian year. The <tt>q</tt> quality character field in the timecode indicates whether a valid timecode has been determined. If any of the high order three bits of this character are set, the timecode is invalid.
-
-<p>Once the clock has been set for the first time, it will appear reachable and selectable to discipline the system clock, even if the broadcast signal is lost. Since the signals are almost always available during some period of the day and the NTP clock discipline algorithms are designed to work well even in this case, it is unlikely that the system clock could drift more than a few tens of milliseconds during periods of signal loss. To protect against this most unlikely situation, if after four days with no signals, the clock is considered unset and resumes the synchronization procedure from the beginning.
-
-<p>The last three fields in the timecode are useful in assessing the quality of the radio channel during the most recent minute bursts were received. The <tt>bcnt</tt> field shows the number of format A bursts in the range 1-8. The <tt>dist</tt> field shows the majority decoder distance, or the minimum number of sample repetitions for each digit of the timecode in the range 0-16. The <tt>tsmp</tt> field shows the number of timestamps determined in the range 0-60. For a valid timecode, <tt>bcnt</tt> must be at least 3, <tt>dist</tt> must be greater than <tt>bcnt</tt> and <tt>tsmp</tt> must be at least 20.
+<p>This driver synchronizes the computer time using data encoded in
+radio transmissions from Canadian time/frequency station CHU in
+Ottawa, Ontario. It replaces an earlier one, built by Dennis
+Ferguson in 1988, which required a special line discipline to
+preprocessed the signal. The new driver includes more powerful
+algorithms implemented directly in the driver and requires no
+preprocessing.</p>
+
+<p>CHU transmissions are made continuously on 3330 kHz, 7335 kHz
+and 14670 kHz in upper sideband, compatible AM mode. An ordinary
+shortwave receiver can be tuned manually to one of these
+frequencies or, in the case of ICOM receivers, the receiver can be
+tuned automatically as propagation conditions change throughout the
+day and night. The performance of this driver when tracking the
+station is ordinarily better than 1 ms in time with frequency drift
+less than 0.5 PPM when not tracking the station.</p>
+
+<p>While there are currently no known commercial CHU receivers, a
+simple but effective receiver/demodulator can be constructed from
+an ordinary shortwave receiver and Bell 103 compatible, 300-b/s
+modem or modem chip, as described in the <a href="gadget.htm">
+Gadget Box PPS Level Converter and CHU Modem</a> page. The driver
+can use the modem to receive the radio signal and demodulate the
+data or, if available, the driver can use the audio codec of the
+Sun workstation or another with compatible audio interface. In the
+latter case, the driver implements the modem using DSP routines, so
+the radio can be connected directly to either the microphone on
+line input port.</p>
+
+<p>This driver incorporates several features in common with other
+audio drivers such as described in the <a href="driver36.htm">Radio
+WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.htm">
+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.htm">Reference Clock Audio Drivers</a> page.</p>
+
+<p>Ordinarily, the driver poll interval is set to 14 (about 4.5 h),
+although this can be changed with configuration commands. As long
+as the clock is set or verified at least once during this interval,
+the NTP algorithms will consider the source reachable and
+selectable to discipline the system clock. However, if this does
+not happen for eight poll intervals, the algorithms will consider
+the source unreachable and some other source will be chosen (if
+available) to discipline the system clock.</p>
+
+<p>The decoding algorithms process the data using
+maximum-likelihood techniques which exploit the considerable degree
+of redundancy available in each broadcast message or burst. As
+described below, every character is sent twice and, in the case of
+format A bursts, the burst is sent eight times every minute. In the
+case of format B bursts, which are sent once each minute, the burst
+is considered correct only if every character matches its
+repetition in the burst. In the case of format A messages, a
+majority decoder requires at least six repetitions for each digit
+in the timecode and more than half of the repetitions decode to the
+same digit. Every character in every burst provides an independent
+timestamp upon arrival with a potential total of over 60 timestamps
+for each minute.</p>
+
+<p>A timecode in the format described below is assembled when all
+bursts have been received in the minute. The timecode is considered
+valid and the clock set when at least one valid format B burst has
+been decoded and the above requirements are met. The <tt>yyyy</tt>
+year field in the timecode indicates whether a valid format B burst
+has been received. Upon startup, this field is initialized at zero;
+when a valid format B burst is received, it is set to the current
+Gregorian year. The <tt>q</tt> quality character field in the
+timecode indicates whether a valid timecode has been determined. If
+any of the high order three bits of this character are set, the
+timecode is invalid.</p>
+
+<p>Once the clock has been set for the first time, it will appear
+reachable and selectable to discipline the system clock, even if
+the broadcast signal is lost. Since the signals are almost always
+available during some period of the day and the NTP clock
+discipline algorithms are designed to work well even in this case,
+it is unlikely that the system clock could drift more than a few
+tens of milliseconds during periods of signal loss. To protect
+against this most unlikely situation, if after four days with no
+signals, the clock is considered unset and resumes the
+synchronization procedure from the beginning.</p>
+
+<p>The last three fields in the timecode are useful in assessing
+the quality of the radio channel during the most recent minute
+bursts were received. The <tt>bcnt</tt> field shows the number of
+format A bursts in the range 1-8. The <tt>dist</tt> field shows the
+majority decoder distance, or the minimum number of sample
+repetitions for each digit of the timecode in the range 0-16. The
+<tt>tsmp</tt> field shows the number of timestamps determined in
+the range 0-60. For a valid timecode, <tt>bcnt</tt> must be at
+least 3, <tt>dist</tt> must be greater than <tt>bcnt</tt> and <tt>
+tsmp</tt> must be at least 20.</p>
<h4>Program Operation</h4>
-<p>The program consists of four major parts: the DSP modem, maximum likelihood UART, burst assembler and majority decoder. The DSP modem demodulates Bell 103 modem answer-frequency signals; that is, frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz (space). This is done using a 4th-order IIR filter and limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and followed by a FIR raised-cosine lowpass filter optimized for the 300-b/s data rate. Alternately, the driver can be compiled to delete the modem and input 300 b/s data directly from an external modem via a serial port.
-
-<p>The maximum likelihood UART is implemented using a set of eight 11-stage shift registers, one for each of eight phases of the 300-b/s bit clock. At each phase a new baseband signal value from the DSP modem is shifted into the corresponding register and the maximum and minimum over all 11 samples computed. This establishes a slice level midway between the maximum and minimum over all stages. For each stage, a signal level above this level is a mark (1) and below is a space (0). A quality metric is calculated for each register with respect to the slice level and the a-priori signal consisting of a mark bit (previous stop bit), space (start) bit, eight arbitrary information bits and the first of the two mark (stop) bits.
-
-<p>The shift registers are processed in round-robin order as each modem value arrives until one of them shows a valid framing pattern consisting of a mark bit, space bit, eight arbitrary data bits and a mark bit. When found, the data bits from the register with the best metric is chosen as the maximum likelihood character and the UART begins to process the next character.
-
-<p>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>A valid burst consists of ten characters in two replicated five-character blocks. A format B block contains the year and other information in ten hexadecimal digits. A format A block contains the timecode in ten decimal digits, the first of which is a framing code (6). The burst assembler must deal with cases where the first character of a format A burst is lost or is noise. This is done using the framing code to correct the phase, either one character early or one character late.
-
-<p>The burst distance is incremented by one for each bit in the first block that matches the corresponding bit in the second block and decremented by one otherwise. In a format B burst the second block is bit-inverted relative to the first, so a perfect burst of five 8-bit characters has distance -40. In a format A block the two blocks are identical, so a perfect burst has distance +40. Format B bursts must be perfect to be acceptable; however, format A bursts, which are further processed by the majority decoder, are acceptable if the distance is at least 28.
-
-<p>Each minute of transmission includes eight format A bursts containing two timecodes for each second from 31 through 39. The majority decoder uses a decoding matrix of ten rows, one for each digit position in the timecode, and 16 columns, one for each 4-bit code combination that might be decoded at that position. In order to use the character timestamps, it is necessary to reliably determine the second number of each burst. In a valid burst, the last digit of the two timecodes in the block must match and the value must be in the range 2-9 and greater than in the previous burst.
-
-<p>As each hex digit of a valid burst is processed, the value at the row corresponding to the digit position in the timecode and column corresponding to the code found at that position is incremented. At the end of each minute of transmission, each row of the decoding matrix encodes the number of occurrences of each code found at the corresponding position of the timecode. However, the first digit (framing code) is always 6, the ninth (second tens) is always 3 and the last (second units) changes for each burst, so are not used.
-
-<p>The maximum over all occurrences at each timecode digit position is the distance for that position and the corresponding code is the maximum likelihood candidate. If the distance is zero, the decoder assumes a miss; if the distance is not more than half the total number of occurrences, the decoder assumes a soft error; if two different codes with the same distance are found, the decoder assumes a hard error. In all these cases the decoder encodes a non-decimal character which will later cause a format error when the timecode is reformatted. The decoding distance is defined as the minimum distance over the first nine digits; the tenth digit varies over the seconds and is uncounted.
-
-<p>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>If the timecode is valid, it is passed to the reference clock interface along with the backdated timestamp offsets accumulated over the minute. A perfect set of nine bursts could generate as many as 90 timestamps, but the maximum the interface can handle is 60. These are processed by the interface using a median filter and trimmed-mean average, so the resulting system clock correction is usually much better than would otherwise be the case with radio noise, UART jitter and occasional burst errors.
+<p>The program consists of four major parts: the DSP modem, maximum
+likelihood UART, burst assembler and majority decoder. The DSP
+modem demodulates Bell 103 modem answer-frequency signals; that is,
+frequency-shift keyed (FSK) tones of 2225 Hz (mark) and 2025 Hz
+(space). This is done using a 4th-order IIR filter and
+limiter/discriminator with 500-Hz bandpass centered on 2125 Hz and
+followed by a FIR raised-cosine lowpass filter optimized for the
+300-b/s data rate. Alternately, the driver can be compiled to
+delete the modem and input 300 b/s data directly from an external
+modem via a serial port.</p>
+
+<p>The maximum likelihood UART is implemented using a set of eight
+11-stage shift registers, one for each of eight phases of the
+300-b/s bit clock. At each phase a new baseband signal value from
+the DSP modem is shifted into the corresponding register and the
+maximum and minimum over all 11 samples computed. This establishes
+a slice level midway between the maximum and minimum over all
+stages. For each stage, a signal level above this level is a mark
+(1) and below is a space (0). A quality metric is calculated for
+each register with respect to the slice level and the a-priori
+signal consisting of a mark bit (previous stop bit), space (start)
+bit, eight arbitrary information bits and the first of the two mark
+(stop) bits.</p>
+
+<p>The shift registers are processed in round-robin order as each
+modem value arrives until one of them shows a valid framing pattern
+consisting of a mark bit, space bit, eight arbitrary data bits and
+a mark bit. When found, the data bits from the register with the
+best metric is chosen as the maximum likelihood character and the
+UART begins to process the next character.</p>
+
+<p>The burst assembler processes characters either from the maximum
+likelihood UART or directly from the serial port as configured. A
+burst begins when a character is received and is processed after a
+timeout interval when no characters are received. If the interval
+between characters is greater than two characters, but less than
+the timeout interval, the burst is rejected as a runt and a new
+burst begun. As each character is received, a timestamp is captured
+and saved for later processing.</p>
+
+<p>A valid burst consists of ten characters in two replicated
+five-character blocks. A format B block contains the year and other
+information in ten hexadecimal digits. A format A block contains
+the timecode in ten decimal digits, the first of which is a framing
+code (6). The burst assembler must deal with cases where the first
+character of a format A burst is lost or is noise. This is done
+using the framing code to correct the phase, either one character
+early or one character late.</p>
+
+<p>The burst distance is incremented by one for each bit in the
+first block that matches the corresponding bit in the second block
+and decremented by one otherwise. In a format B burst the second
+block is bit-inverted relative to the first, so a perfect burst of
+five 8-bit characters has distance -40. In a format A block the two
+blocks are identical, so a perfect burst has distance +40. Format B
+bursts must be perfect to be acceptable; however, format A bursts,
+which are further processed by the majority decoder, are acceptable
+if the distance is at least 28.</p>
+
+<p>Each minute of transmission includes eight format A bursts
+containing two timecodes for each second from 31 through 39. The
+majority decoder uses a decoding matrix of ten rows, one for each
+digit position in the timecode, and 16 columns, one for each 4-bit
+code combination that might be decoded at that position. In order
+to use the character timestamps, it is necessary to reliably
+determine the second number of each burst. In a valid burst, the
+last digit of the two timecodes in the block must match and the
+value must be in the range 2-9 and greater than in the previous
+burst.</p>
+
+<p>As each hex digit of a valid burst is processed, the value at
+the row corresponding to the digit position in the timecode and
+column corresponding to the code found at that position is
+incremented. At the end of each minute of transmission, each row of
+the decoding matrix encodes the number of occurrences of each code
+found at the corresponding position of the timecode. However, the
+first digit (framing code) is always 6, the ninth (second tens) is
+always 3 and the last (second units) changes for each burst, so are
+not used.</p>
+
+<p>The maximum over all occurrences at each timecode digit position
+is the distance for that position and the corresponding code is the
+maximum likelihood candidate. If the distance is zero, the decoder
+assumes a miss; if the distance is not more than half the total
+number of occurrences, the decoder assumes a soft error; if two
+different codes with the same distance are found, the decoder
+assumes a hard error. In all these cases the decoder encodes a
+non-decimal character which will later cause a format error when
+the timecode is reformatted. The decoding distance is defined as
+the minimum distance over the first nine digits; the tenth digit
+varies over the seconds and is uncounted.</p>
+
+<p>The result of the majority decoder is a nine-digit timecode
+representing the maximum likelihood candidate for the transmitted
+timecode in that minute. Note that the second and fraction within
+the minute are always zero and that the actual reference point to
+calculate timestamp offsets is backdated to the first second of the
+minute. At this point the timecode block is reformatted and the
+year, days, hours and minutes extracted along with other
+information from the format B burst, including DST state, DUT1
+correction and leap warning. The reformatting operation checks the
+timecode for invalid code combinations that might have been left by
+the majority decoder and rejects the entire timecode if found.</p>
+
+<p>If the timecode is valid, it is passed to the reference clock
+interface along with the backdated timestamp offsets accumulated
+over the minute. A perfect set of nine bursts could generate as
+many as 90 timestamps, but the maximum the interface can handle is
+60. These are processed by the interface using a median filter and
+trimmed-mean average, so the resulting system clock correction is
+usually much better than would otherwise be the case with radio
+noise, UART jitter and occasional burst errors.</p>
<h4>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. The serial port speed is presently compiled in the program, but can be changed in the <tt>icom.h</tt> header file.
-
-<p>Each ICOM radio is assigned a unique 8-bit ID select code, usually expressed in hex format. To activate the CI-V interface, the <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies a nonzero select code in decimal format. A table of ID select codes for the known ICOM radios is given below. Since all ICOM select codes are less than 128, the high order bit of the code is used by the driver to specify the baud rate. If this bit is not set, the rate is 9600 bps for the newer radios; if set, the rate is 1200 bps for the older radios. A missing <tt>mode</tt> keyword or a zero argument leaves the interface disabled.
-
-<p>If specified, the driver will attempt to open the device <tt>/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz. If after five minutes at this frequency not more than two format A bursts have been received for any minute, the driver will tune to 7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and continue in this cycle. However, the driver is liberal in what it assumes of the configuration. If the <tt>/dev/icom</tt> link is not present or the open fails or the CI-V bus or radio is inoperative, the driver quietly gives up with no harm done.
+<p>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. The serial port speed is
+presently compiled in the program, but can be changed in the <tt>
+icom.h</tt> header file.</p>
+
+<p>Each ICOM radio is assigned a unique 8-bit ID select code,
+usually expressed in hex format. To activate the CI-V interface,
+the <tt>mode</tt> keyword of the <tt>server</tt> configuration
+command specifies a nonzero select code in decimal format. A table
+of ID select codes for the known ICOM radios is given below. Since
+all ICOM select codes are less than 128, the high order bit of the
+code is used by the driver to specify the baud rate. If this bit is
+not set, the rate is 9600 bps for the newer radios; if set, the
+rate is 1200 bps for the older radios. A missing <tt>mode</tt>
+keyword or a zero argument leaves the interface disabled.</p>
+
+<p>If specified, the driver will attempt to open the device <tt>
+/dev/icom</tt> and, if successful will tune the radio to 3.330 MHz.
+If after five minutes at this frequency not more than two format A
+bursts have been received for any minute, the driver will tune to
+7.335 MHz, then to 14.670 MHz, then return to 3.330 MHz and
+continue in this cycle. However, the driver is liberal in what it
+assumes of the configuration. If the <tt>/dev/icom</tt> link is not
+present or the open fails or the CI-V bus or radio is inoperative,
+the driver quietly gives up with no harm done.</p>
<h4>Radio Broadcast Format</h4>
-<p>The CHU time broadcast includes an audio signal compatible with the Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of nine, ten-character bursts transmitted at 300 b/s and beginning each second from second 31 to second 39 of the minute. Each character consists of eight data bits plus one start bit and two stop bits to encode two hex digits. The burst data consist of five characters (ten hex digits) followed by a repeat of these characters. In format A, the characters are repeated in the same polarity; in format B, the characters are repeated in the opposite polarity.
+<p>The CHU time broadcast includes an audio signal compatible with
+the Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It
+consist of nine, ten-character bursts transmitted at 300 b/s and
+beginning each second from second 31 to second 39 of the minute.
+Each character consists of eight data bits plus one start bit and
+two stop bits to encode two hex digits. The burst data consist of
+five characters (ten hex digits) followed by a repeat of these
+characters. In format A, the characters are repeated in the same
+polarity; in format B, the characters are repeated in the opposite
+polarity.</p>
-<p>Format A bursts are sent at seconds 32 through 39 of the minute in hex digits
+<p>Format A bursts are sent at seconds 32 through 39 of the minute
+in hex digits</p>
-<p><tt>6dddhhmmss6dddhhmmss</tt>
+<p><tt>6dddhhmmss6dddhhmmss</tt></p>
-<p>The first ten digits encode a frame marker (<tt>6</tt>) followed by the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>) and second (<tt>ss</tt>). Since format A bursts are sent during the third decade of seconds the tens digit of <tt>ss</tt> is always 3. The driver uses this to determine correct burst synchronization. These digits are then repeated with the same polarity.
+<p>The first ten digits encode a frame marker (<tt>6</tt>) followed
+by the day (<tt>ddd</tt>), hour (<tt>hh</tt>), minute (<tt>mm</tt>)
+and second (<tt>ss</tt>). Since format A bursts are sent during the
+third decade of seconds the tens digit of <tt>ss</tt> is always 3.
+The driver uses this to determine correct burst synchronization.
+These digits are then repeated with the same polarity.</p>
-<p>Format B bursts are sent at second 31 of the minute in hex digits
+<p>Format B bursts are sent at second 31 of the minute in hex
+digits</p>
-<p><tt>xdyyyyttaaxdyyyyttaa</tt>
+<p><tt>xdyyyyttaaxdyyyyttaa</tt></p>
-<p>The first ten digits encode a code (<tt>x</tt> described below) followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year (<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight time indicator (<tt>aa</tt>) peculiar to Canada. These digits are then repeated with inverted polarity.
+<p>The first ten digits encode a code (<tt>x</tt> described below)
+followed by the DUT1 (<tt>d</tt> in deciseconds), Gregorian year
+(<tt>yyyy</tt>), difference TAI - UTC (<tt>tt</tt>) and daylight
+time indicator (<tt>aa</tt>) peculiar to Canada. These digits are
+then repeated with inverted polarity.</p>
-<p>The <tt>x</tt> is coded
+<p>The <tt>x</tt> is coded</p>
<dl>
+<dt><tt>1</tt></dt>
+
+<dd>Sign of DUT (0 = +)/dd></dd>
-<dt><tt>1</tt>
-<dd>Sign of DUT (0 = +)/dd>
+<dt><tt>2</tt></dt>
-<dt><tt>2</tt>
<dd>Leap second warning. One second will be added.</dd>
-<dt><tt>4</tt>
-<dd>Leap second warning. One second will be subtracted. This is not likely to happen in our universe.</dd>
+<dt><tt>4</tt></dt>
-<dt><tt>8</tt>
-<dd>Even parity bit for this nibble.</dd>
+<dd>Leap second warning. One second will be subtracted. This is not
+likely to happen in our universe.</dd>
+<dt><tt>8</tt></dt>
+
+<dd>Even parity bit for this nibble.</dd>
</dl>
-<p>By design, the last stop bit of the last character in the burst coincides with 0.5 second. Since characters have 11 bits and are transmitted at 300 b/s, the last stop bit of the first character coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the UART, character interrupts can vary somewhere between the beginning of bit 9 and end of bit 11. These eccentricities can be corrected along with the radio propagation delay using the <tt>fudge time1</tt> variable.
+<p>By design, the last stop bit of the last character in the burst
+coincides with 0.5 second. Since characters have 11 bits and are
+transmitted at 300 b/s, the last stop bit of the first character
+coincides with 0.5 - 10 * 11/300 = 0.133 second. Depending on the
+UART, character interrupts can vary somewhere between the beginning
+of bit 9 and end of bit 11. These eccentricities can be corrected
+along with the radio propagation delay using the <tt>fudge
+time1</tt> variable.</p>
<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>The most convenient way to track the program status is using the
+<tt>ntpq</tt> program and the <tt>clockvar</tt> command. This
+displays the last determined timecode and related status and error
+counters, even when the program is not discipline the system clock.
+If the debugging trace feature (<tt>-d</tt> on the <tt>ntpd</tt>
+command line)is enabled, the program produces detailed status
+messages as it operates. If the <tt>fudge flag 4</tt> is set, these
+messages are written to the <tt>clockstats</tt> file. All messages
+produced by this driver have the prefix <tt>chu</tt> for convenient
+filtering with the Unix <tt>grep</tt> command.</p>
-<p>With debugging enabled the driver produces messages in the following formats:
+<p>With debugging enabled the driver produces messages in the
+following formats:</p>
-<p>A format <tt>chuA</tt> message is produced for each format A burst received in seconds 32 through 39 of the minute:
+<p>A format <tt>chuA</tt> message is produced for each format A
+burst received in seconds 32 through 39 of the minute:</p>
-<p><tt>chuA n b s code</tt>
+<p><tt>chuA n b s code</tt></p>
-<p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>s</tt> the synchronization distance (0-40) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed and the last ten digits inverted, so the burst
+<p>where <tt>n</tt> is the number of characters in the burst
+(0-11), <tt>b</tt> the burst distance (0-40), <tt>s</tt> the
+synchronization distance (0-40) and <tt>code</tt> the burst
+characters as received. Note that the hex digits in each character
+are reversed and the last ten digits inverted, so the burst</p>
-<p><tt>11 40 1091891300ef6e76ecff</tt>
+<p><tt>11 40 1091891300ef6e76ecff</tt></p>
-<p>is interpreted as containing 11 characters with burst distance 40. The nibble-swapped timecode shows DUT1 +0.1 second, year 1998 and TAI -UTC 31 seconds.
+<p>is interpreted as containing 11 characters with burst distance
+40. The nibble-swapped timecode shows DUT1 +0.1 second, year 1998
+and TAI -UTC 31 seconds.</p>
-<p>A format <tt>chuB</tt> message is produced for each format B burst received in second 31 of the minute:
+<p>A format <tt>chuB</tt> message is produced for each format B
+burst received in second 31 of the minute:</p>
-<p><tt>chuB n b f s m code</tt>
+<p><tt>chuB n b f s m code</tt></p>
-<p>where <tt>n</tt> is the number of characters in the burst (0-11), <tt>b</tt> the burst distance (0-40), <tt>f</tt> the field alignment (-1, 0, 1), <tt>s</tt>the synchronization distance (0-16), <tt>m</tt>the burst number (2-9) and <tt>code</tt> the burst characters as received. Note that the hex digits in each character are reversed, so the burst
+<p>where <tt>n</tt> is the number of characters in the burst
+(0-11), <tt>b</tt> the burst distance (0-40), <tt>f</tt> the field
+alignment (-1, 0, 1), <tt>s</tt>the synchronization distance
+(0-16), <tt>m</tt>the burst number (2-9) and <tt>code</tt> the
+burst characters as received. Note that the hex digits in each
+character are reversed, so the burst</p>
-<p><tt>10 38 0 16 9 06851292930685129293</tt>
+<p><tt>10 38 0 16 9 06851292930685129293</tt></p>
-<p>is interpreted as containing 11 characters with burst distance 38, field alignment 0, synchronization distance 16 and burst number 9. The nibble-swapped timecode shows day 58, hour 21, minute 29 and second 39.
+<p>is interpreted as containing 11 characters with burst distance
+38, field alignment 0, synchronization distance 16 and burst number
+9. The nibble-swapped timecode shows day 58, hour 21, minute 29 and
+second 39.</p>
-<p>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>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:
+When enabled by the <tt>filegen</tt> facility, every received
+timecode is written to the <tt>clockstats</tt> file in the
+following format:
<pre>
sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp
tsmp timestamps captured
</pre>
-The fields beginning with <tt>year</tt> and extending through <tt>dut</tt> are decoded from the received data and are in fixed-length format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the following driver-dependent fields, are in variable-length format.
+The fields beginning with <tt>year</tt> and extending through <tt>
+dut</tt> are decoded from the received data and are in fixed-length
+format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the
+following driver-dependent fields, are in variable-length format.
<dl>
+<dt><tt>s</tt></dt>
+
+<dd>The sync indicator is initially <tt>?</tt> before the clock is
+set, but turns to space when the clock is correctly set.</dd>
-<dt><tt>s</tt>
-<dd>The sync indicator is initially <tt>?</tt> before the clock is set, but turns to space when the clock is correctly set.</dd>
+<dt><tt>q</tt></dt>
-<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:
+<dd>The quality character is a four-bit hexadecimal code showing
+which alarms have been raised during the most recent minute. Each
+bit is associated with a specific alarm condition according to the
+following:
<dl>
-<dt><tt>8</tt>
-<dd>Decoder alarm. A majority of repetitions for at least one digit of the timecode fails to agree.
-</dd>
+<dt><tt>8</tt></dt>
-<dt><tt>4</tt>
-<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd>
+<dd>Decoder alarm. A majority of repetitions for at least one digit
+of the timecode fails to agree.</dd>
-<dt><tt>2</tt>
-<dd>Format alarm. The majority timecode contains invalid bit combinations.</dd>
+<dt><tt>4</tt></dt>
-<dt><tt>1</tt>
-<dd>Frame alarm. A framing or format error occurred on at least one burst during the minute.</dd>
+<dd>Timestamp alarm. Fewer than 20 timestamps have been
+determined.</dd>
+<dt><tt>2</tt></dt>
+
+<dd>Format alarm. The majority timecode contains invalid bit
+combinations.</dd>
+
+<dt><tt>1</tt></dt>
+
+<dd>Frame alarm. A framing or format error occurred on at least one
+burst during the 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 condition that may in future result in an error.
+It is important to note that one or more of the above alarms does
+not necessarily indicate a clock error, but only that the decoder
+has detected a condition that may in future result in an
+error.</dd>
+
+<dt><tt>yyyy ddd hh:mm:ss.fff</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>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 of June
+or December.</dd>
+
+<dt><tt>d</tt></dt>
+
+<dd>The DST code for Canada encodes the state for all
+provinces.</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.</dd>
+
+<dt><tt>lset</tt></dt>
+
+<dd>Before the clock is set, the interval since last set is the
+number of minutes since the program was started; after the clock is
+set, this is number of minutes since the time was last verified
+relative to the broadcast signal.</dd>
-<dt><tt>yyyy ddd hh:mm:ss.fff</tt></tt>
-<dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.</dd>
+<dt><tt>agc</tt></dt>
-<dt><tt>l</tt>
-<dd>The leap second warning is normally space, but changes to <tt>L</tt> if a leap second is to occur at the end of the month of June or December.</dd>
+<dd>The audio gain shows the current codec gain setting in the
+range 0 to 255. Ordinarily, the receiver audio gain control or IRIG
+level control should be set for a value midway in this range.</dd>
-<dt><tt>d</tt>
-<dd>The DST code for Canada encodes the state for all provinces.</dd>
+<dt><tt>rfrq</tt></dt>
-<dt><tt>dut</tt>
-<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.</dd>
+<dd>The current radio frequency, if the CI-V interface is active,
+or 'X' if not.</dd>
-<dt><tt>lset</tt>
-<dd>Before the clock is set, the interval since last set is the number of minutes since the program was started; after the clock is set, this
-is number of minutes since the time was last verified relative to the
-broadcast signal.</dd>
+<dt><tt>bcnt</tt></dt>
-<dt><tt>agc</tt>
-<dd>The audio gain shows the current codec gain setting in the range 0
-to 255. Ordinarily, the receiver audio gain control or IRIG level
-control should be set for a value midway in this range.
+<dd>The number of format A bursts received during the most recent
+minute bursts were received.</dd>
-<dt><tt>rfrq</tt>
-<dd>The current radio frequency, if the CI-V interface is active, or 'X'
-if not.</dd>
+<dt><tt>dist</tt></dt>
-<dt><tt>bcnt</tt>
-<dd>The number of format A bursts received during the most recent minute bursts were received.</dd>
+<dd>The minimum decoding distance determined during the most recent
+minute bursts were received.</dd>
-<dt><tt>dist</tt>
-<dd>The minimum decoding distance determined during the most recent minute bursts were received.</dd>
+<dt><tt>tsmp</tt></dt>
-<dt><tt>tsmp</tt>
-<dd>The number of timestamps determined during the most recent minute bursts were received.</dd>
+<dd>The number of timestamps determined during the most recent
+minute bursts were received.</dd>
</dl>
<h4>Modes</h4>
-<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration command specifies the ICOM ID select code. A missing or zero argument disables the CI-V interface. Following are the ID select codes for the known radios.
-
-<p><table cols=6 width=100%>
+<p>The <tt>mode</tt> keyword of the <tt>server</tt> configuration
+command specifies the ICOM ID select code. A missing or zero
+argument disables the CI-V interface. Following are the ID select
+codes for the known radios.</p>
+<table cols="6" width="100%">
<tr>
<td>Radio</td>
<td>Hex</td>
<td>0x2a</td>
<td>42</td>
</tr>
-
</table>
<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>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>
-<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>stratum <i>number</i></tt></dt>
-<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>
+<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>
+
+<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>
+
+<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>
+<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
</dl>
<h4>Additional Information</h4>
-<A HREF="refclock.htm">Reference Clock Drivers</A>
-<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
+<a href="refclock.htm">Reference Clock Drivers</a> <br>
+<a href="audio.htm">Reference Clock Audio Drivers</a>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a></address></a></body></html>
Network Time Synchronization</a> page. Discussion on protocol
conformance issues and interoperability with previous NTP versions
can be found in the <a href="biblio.htm">Protocol Conformance
-Statement</a> page. Discussion on year-2000 issues can be found in
-the <a href="y2k.htm">Year 2000 Conformance Statement page</a>.
+Statement</a> page. Discussion on how NTP reckons the time can be found in the <a href="leap.htm">NTP Timescale and Leap Seconds</a> page.
Background information, bibliography and briefing slides suitable
for presentations can be found in the <a href=
"http://www.eecis.udel.edu/~mills/ntp.htm">Network Time
<li><a href="biblio.htm">Protocol Conformance Statement</a></li>
-<li><a href="y2k.htm">Year 2000 Conformance Statement</a></li>
+<li><a href="leap.htm">NTP Timescale and Leap Seconds</a></li>
<li><a href="notes.htm">Notes on Configuring NTP and Setting up a
NTP Subnet</a></li>
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title>NTP Timescale and Leap Seconds</title>
+</head>
+<body>
+<h3>NTP Timescale and Leap Seconds</h3>
+
+<img align="left" src="pic/alice15.gif" alt="gif"><a href=
+"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
+Carroll</a>
+
+<p>The Mad Hatter and the March Hare are discussing whether the
+Teapot serial number should have two or four digits.<br clear=
+"left">
+</p>
+
+<hr>
+<h4>Introduction</h4>
+
+<p>In the year 2001 the Network Time Protocol (NTP) has been in use
+for over two decades and remains the longest running, continuously
+operating application protocol in the Internet. There was some
+concern, especially in government and financial institutions, that
+NTP might cause Internet applications to misbehave in terrible ways
+on the epoch of the new century, but this didn't happen. However,
+how NTP reckons the time is important when considering the
+relationship between NTP time and conventional civil time.</p>
+
+<p>This document presents an analysis of the NTP timescale, in
+particular the metrication relative to the conventional civil
+timescale and when the NTP timescale rolls over in 2036. These
+issues are also important with respect to the Unix timescale, but
+that rollover will not happen until 2038. This document does not
+establish a standard, nor does it present specific algorithms which
+metricate the NTP timescale with respect to other timescales.</p>
+
+<h4>The NTP Timescale</h4>
+
+<p>It will be helpful in understanding the issues raised in this
+document to consider the concept of a universal timescale. The
+conventional civil timescale used in most parts of the world is
+based on Coordinated Universal Time (UTC) (sic), formerly known as
+Greenwich Mean Time (GMT). UTC is based on International Atomic
+Time (TAI sic), which is derived from hundreds of cesium clocks in
+the national standards laboratories of many countries. Deviations
+of UTC from TAI are implemented in the form of leap seconds, which
+occur on average every eighteen months.</p>
+
+<p>For almost every computer application today, UTC represents the
+universal timescale extending into the indefinite past and
+indefinite future. We know of course that the UTC timescale did not
+exist prior to 1972, the Gregorian calendar did not exist prior to
+1582, the Julian calendar did not exist prior to 54 BC and we
+cannot predict exactly when the next leap second will occur.
+Nevertheless, most folks would prefer that, even if we can't get
+future seconds numbering right beyond the next leap second, at
+least we can get the days numbering right until the end of
+reason.</p>
+
+<p>The universal timescale can be implemented using a binary
+counter of indefinite width and with the unit seconds bit placed
+somewhere in the middle. The counter is synchronized to UTC such
+that it runs at the same rate (also the rate of TAI) and the units
+increment coincides with the UTC seconds tick. The NTP timescale is
+constructed from 64 bits of this counter, of which 32 bits number
+the seconds and 32 bits represent the fraction. With this design,
+the counter runs in 136-year cycles, called eras, the latest of
+which began with a counter value of zero at 0h 1 January 1900. The
+next era will begin when the seconds counter rolls over sometime in
+2036. The design assumption is that further low order bits, if
+required, are provided by local interpolation, while further high
+order bits, when required, are provided by external means.</p>
+
+<p>The important point to be made here is that the high order bits
+must ultimately be provided by astronomers and disseminated to the
+population by international means. Ultimately, should a need exist
+to align a particular NTP era to the current calendar, the
+operating system in which NTP is embedded must provide the
+necessary high order bits, most conveniently from the file system
+or flash memory.</p>
+
+<p>With respect to the recent year 2000 issue, the most important
+thing to observe about the NTP timescale is that it knows nothing
+about days, years or centuries, only the seconds since the
+beginning of the current era which began on 1 January 1900. On 1
+January 1970 when Unix life began, the NTP timescale showed
+2,208,988,800 and on 1 January 1972 when UTC life began, it showed
+2,272,060,800. On the last second of the year 1999, the NTP
+timescale showed 3,155,673,599 and one second later on the first
+second of the next century showed 3,155,673,600. Other than this
+observation, the NTP timescale has no knowledge of or provision for
+any of these eclectic seconds.</p>
+
+<h4>Conversion to Other Timescales</h4>
+
+<p>The NTP timescale is almost never used directly by system or
+application programs. The generic Unix kernel keeps time in seconds
+and microseconds (or nanoseconds) to provide both time of day and
+interval timer functions. In order to synchronize the Unix clock,
+NTP must convert to and from NTP representation and Unix
+representation. Unix kernels implement the time of day function
+using two 32-bit counters, one representing the signed seconds
+since Unix life began and the other the microseconds or nanoseconds
+of the second. In principle, the seconds counter will change sign
+in 2038. How the particular Unix semantics interprets the counter
+values is of concern, but is beyond the scope of discussion
+here.</p>
+
+<p>While incorrect NTP time values are unlikely in a properly
+configured subnet using strong cryptography, redundant sources and
+diverse network paths, hazards remain due to incorrect software
+external to NTP. These include the Unix kernel and library routines
+which convert NTP time to and from Unix time and to and from
+conventional civil time in seconds, minutes, hours, days and years.
+Although NTP uses these routines to format monitoring data
+displays, they are not used to read or set the NTP clock. They may
+in fact cause problems with certain application programs, but this
+is not an issue which concerns NTP correctness.</p>
+
+<p>It is possible that some external source to which NTP
+synchronizes may produce a discontinuity which could then induce a
+NTP discontinuity. The NTP primary (stratum 1) time servers, which
+are the ultimate time references for the entire NTP population,
+obtain time from various sources, including radio and satellite
+receivers and telephone modems. Not all sources provide year
+information and not all of these provide time in four-digit form.
+In point of fact, the NTP reference implementation does not use the
+year information, even if available. Instead, the year information
+is provided from the file system, which itself depends on the Unix
+clock.</p>
+
+<p>Most computers include a time-of-year (TOY) clock chip which
+maintains the time when the power is off. When the operating system
+is booted, the system clock is set from the chip. As the chip does
+not record the year, this value is determined from the datestamp on
+a system configuration file. For this to be correct, the filestamp must by updated at least once each year. The NTP protocol specification
+requires the apparent NTP time derived from external servers to be
+compared to the system time before the clock is set. If the
+discrepancy is over 1000 seconds, an error alarm is raised
+requiring manual intervention. This makes it very unlikely that
+even a clique of seriously corrupted NTP servers will result in
+grossly incorrect time values. When the system clock is synchronized to
+NTP, the TOY chip is corrected to system time on a regular
+basis.</p>
+
+<h4>Timescale Resolution and the Tick Interval</h4>
+
+<p>Modern computer clocks use a hardware counter to generate processor interrupts at tick intervals in the order of a few milliseconds. At each tick the processor increments the software system clock by the number of microseconds or nanoseconds in the tick. The software resolution of the system clock is defined as the tick interval. Most modern processors implement some kind of high resolution hardware counter that can be used to interpolate the interval between the most recent tick and the actual clock reading. The hardware resolution of the system clock is defined as the time between increments of this counter. However, the actual reading latency due to the kernel interface and interpolation code can range from a few tens of microseconds in older processors to under a microsecond in modern processors.</p>
+
+<p>System clock correctness principles require that clock readings must be always monotonically increasing, so that no two clock readings will be the same. As long as the reading latency exceeds the hardware resolution, this behavior is guaranteed. With reading latencies dropping below the microsecond in modern processors, the system clock in modern operating systems runs in nanoseconds, rather than the microseconds used in the original Unix kernel. With processor speeds exceeding 1 GHz, this assumption may be in jeopardy.
+
+<h4>Leap Seconds</h4>
+
+<p>The International Earth Rotation Service (IERS) uses
+astronomical observations provided by USNO and other observatories
+to determine UTC, which is syntonic (identical frequency) with TAI
+but offset by a integral number of seconds. Starting from apparent
+mean solar time as observed, the UT0 timescale is determined using
+corrections for Earth orbit and inclination (the Equation of Time,
+as used by sundials), the UT1 (navigator's) timescale by adding
+corrections for polar migration and the UT2 timescale by adding
+corrections for known periodicity variations. UTC is based on UT1,
+which is presently fast relative to TAI by a fraction of a second
+per year. Since the UTC timescale runs at the TAI rate, when the
+magnitude of the UT1 correction approaches 0.5 second, a leap
+second is inserted or deleted in the UTC timescale on the last day
+of June or December.</p>
+
+<p>For the most precise coordination and timestamping of events
+since 1972, it is necessary to know when leap seconds are
+implemented in UTC and how the seconds are numbered. The insertion
+of leap seconds into UTC is currently the responsibility of the
+IERS, which is located at the Paris Observatory. As specified in
+CCIR Report 517, a leap second is inserted following second
+23:59:59 on the last day of June or December and becomes second
+23:59:60 of that day. A leap second would be deleted by omitting
+second 23:59:59 on one of these days, although this has never
+happened. A table of historic leap seconds and the NTP time when
+each occurred is available via FTP from any NIST NTP server.</p>
+
+<p>The UTC timescale thus ticks in standard (atomic) seconds and
+was set to an initial offset of 10 seconds relative to TAI at 0h
+MJD 41,318.0 according to the Julian calendar or 0h on 1 January
+1972 according to the Gregorian calendar. This established the
+first tick of the UTC era and its reckoning with these calendars.
+Subsequently, the UTC timescale has marched backward relative to
+the TAI timescale exactly one second on scheduled occasions
+recorded in the institutional memory of our civilization. Note in
+passing that leap second adjustments affect the number of seconds
+per day and thus the number of seconds per year. Apparently, should
+we choose to worry about it, the UTC clock, Gregorian calendar and
+various cosmic oscillators will inexorably drift apart with time
+until rationalized by some future papal bull.</p>
+
+<h4>Reckoning with NTP and UTC Leap seconds</h4>
+
+<p>The NTP timescale is based on the UTC timescale, but not
+necessarily always coincident with it. At the first tick of the UTC
+Era, which began at 0h on 1 January 1972 (MJD 41,318.0) the NTP
+clock read 2,272,060,800, representing the number of standard
+seconds since the beginning of the NTP era at 0h on 1 January 1900
+(MJD 15,021.0) according to the Gregorian calendar. The insertion
+of leap seconds in UTC and subsequently into NTP does not affect
+the UTC or NTP oscillator frequency, only the conversion between
+NTP network time and UTC civil time. However, since the only
+institutional memory available to NTP are the UTC broadcast
+services, the NTP timescale is in effect reset to UTC as each
+broadcast timecode is received. Thus, when a leap second is
+inserted in UTC and subsequently in NTP, knowledge of all previous
+leap seconds is lost.</p>
+
+<p>Another way to describe this is to say there are as many NTP
+timescales as historic leap seconds. In effect, a new timescale is
+established after each new leap second. Thus, all previous leap
+seconds, not to mention the apparent origin of the timescale
+itself, lurch forward one second as each new timescale is
+established. If a clock synchronized to NTP in early 2001 was used
+to establish the UTC epoch of an event that occurred in early 1972
+without correction, the event would appear 22 seconds late.
+However, NTP primary time servers resolve the epoch using the
+broadcast timecode, so that the NTP clock is set to the broadcast
+value on the current timescale. As a result, for the most precise
+determination of epoch relative to the historic Gregorian calendar
+and UTC timescale, the user must subtract from the apparent NTP
+epoch the offsets derived from the NIST table. This is a feature of
+almost all present day time distribution mechanisms.</p>
+
+<p>The obvious question raised by this scenario is what happens
+during the leap second when NTP time stops and the clock remains
+unchanged. If the precision time kernel modifications have been
+implemented, the kernel includes a state machine that implements
+the actions required by the scenario. At the exact instant of the
+leap, the logical clock is stepped backward one second. However,
+the routine that actually reads the clock is constrained never to
+step backwards, unless the step is significantly larger than one
+second, which might occur due to explicit operator direction.</p>
+
+<p>In this design time stands still during the leap second, but is correct commencing with the next second. Since clock readings must be positive monotonic, the apparent time will increase by one nanosecond for each reading. At the end of the second the apparent time may be ahead of the actual time depending on how many times the clocks was read during the second. Eventually, the actual time will catch up with the apparent time and operation continues normally.</p>
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"gif"></a>
+
+<address><a href="mailto:mills@udel.edu">David L. Mills
+<mills@udel.edu></a></address>
+</body>
+</html>
+
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
-&lt;html>
-<html>
-<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Network Time Protocol Year 2000 Conformance
-Statement</title>
-</head>
-<body>
-<h3>Network Time Protocol Year 2000 Conformance Statement</h3>
-
-<img align="left" src="pic/alice15.gif" alt="gif"><a href=
-"pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
-Carroll</a>
-
-<p>The Mad Hatter and the March Hare are discussing whether the
-Teapot serial number should have two or four digits.<br clear=
-"left">
-</p>
-
-<hr>
-<h4>Introduction</h4>
-
-By the year 2000, the Network Time Protocol (NTP) will have been in
-use for over two decades and remain the longest running,
-continuously operating application protocol in the Internet. There
-is some concern, especially in government and financial
-institutions, that NTP might cause Internet applications to
-misbehave in terrible ways on the epoch of the next century. This
-document presents an analysis of the various hazards that might
-result in incorrect time values upon this epoch. It concludes that
-incorrect time values due to the NTP timescale, protocol design and
-reference implementation are highly unlikely. However, it is
-possible that external reference time sources used by NTP could
-misbehave and cause NTP servers to distribute incorrect time values
-to significant portions of the Internet. Note that, while this
-document addresses the issues specifically with respect to Unix
-systems, the issues are equally applicable to Windows and VMS
-systems.
-
-<h4>The NTP Timescale</h4>
-
-It will be helpful in understanding the issues raised in this
-document to consider the concept of a universal timescale. The
-conventional civil timescale used in most parts of the world is
-based on Universal Coordinated Time (UTC sic), formerly known as
-Greenwich Mean Time (GMT). UTC is based on International Atomic
-Time (TAI sic), which is derived from hundreds of cesium clocks in
-the national standards laboratories of many countries. Deviations
-of UTC from TAI are implemented in the form of leap seconds, which
-occur on average every eighteen months. For almost every computer
-application today, UTC represents the universal timescale extending
-into the indefinite past and indefinite future. We know of course
-that the UTC timescale did not exist prior to 1972, the Gregorian
-calendar did not exist prior to 1582, the Julian calendar did not
-exist prior to 54 BC and we cannot predict exactly when the next
-leap second will occur. Nevertheless, most folks would prefer that,
-even if we can't get future seconds numbering right beyond the next
-leap second, at least we can get the days numbering right until the
-end of reason.
-
-<p>The universal timescale can be implemented using a binary
-counter of indefinite width and with the unit seconds bit placed
-somewhere in the middle. The counter is synchronized to UTC such
-that it runs at the same rate and the units increment coincides
-with the UTC seconds tick. The NTP timescale is constructed from 64
-bits of this counter, of which 32 bits number the seconds and 32
-bits represent the fraction. With this design, the counter runs in
-136-year cycles, called eras, the latest of which began with a
-counter value of zero at 0h 1 January 1900. The design assumption
-is that further low order bits, if required, are provided by local
-interpolation, while further high order bits, when required, are
-provided by external means. The important point to be made here is
-that the high order bits must ultimately be provided by astronomers
-and disseminated to the population by international means.
-Ultimately, should a need exist to align a particular NTP era to
-the current calendar, the operating system in which NTP is embedded
-must provide the necessary high order bits, most conveniently from
-the file system or flash memory.</p>
-
-<h4>The Year 2000 Era</h4>
-
-With respect to the year 2000 issue, the most important thing to
-observe about the NTP timescale is that it knows nothing about
-days, years or centuries, only the seconds since the beginning of
-the latest era, the current one of which began on 1 January 1900.
-On 1 January 1970 when Unix life began, the NTP timescale showed
-2,208,988,800 and on 1 January 1972 when UTC life began, it showed
-2,272,060,800. On the last second of year 1999, the NTP timescale
-will show 3,155,673,599 and one second later on the first second of
-the next century will show 3,155,673,600. Other than this
-observation, the NTP timescale has no knowledge of or provision for
-any of these eclectic seconds.
-
-<p>The NTP timescale is almost never used directly by system or
-application programs. The generic Unix kernel keeps time in seconds
-and microseconds (or nanoseconds) to provide both time of day and
-interval timer functions. In order to synchronize the Unix clock,
-NTP must convert to and from its representation and Unix
-representation. Unix kernels implement the time of day function
-using two 32-bit counters, one representing the seconds since Unix
-life began and the other the microseconds or nanoseconds of the
-second. In principle, the seconds counter will wrap around in
-136-year eras, the next of which will begin in 2106. How the
-particular Unix semantics interprets the counter values is of
-concern, but is beyond the scope of discussion here.</p>
-
-<p>While incorrect time values due to the NTP timescale and
-protocol design or reference implementation upon the epoch of the
-next century are highly unlikely, hazards remain due to incorrect
-software external to NTP. These hazards include the Unix kernel and
-library routines which convert Unix time to and from conventional
-civil time in seconds, minutes, hours, days and years. Although NTP
-uses these routines to format monitoring data displays, they are
-not used to read or set the NTP clock. They may in fact cause
-problems with certain application programs, but this is not an
-issue which concerns NTP correctness.</p>
-
-<p>While it is extremely unlikely that NTP will produce incorrect
-time values upon the epoch, it is possible that some external
-source to which NTP synchronizes may produce a discontinuity which
-could then induce a NTP discontinuity. The NTP primary (stratum 1)
-time servers, which are the ultimate time references for the entire
-NTP population, obtain time from various sources, including radio
-and satellite receivers and telephone modems. Not all sources
-provide year information and not all of these provide time in
-four-digit form. In point of fact, the NTP reference implementation
-does not use the year information, even if available. Instead, the
-year information is provided from the file system, which itself
-depends on the Unix clock.</p>
-
-<p>The NTP protocol specification requires the apparent NTP time
-derived from external servers to be compared to the file system
-time before the clock is set. If the discrepancy is over 1000
-seconds, an error alarm is raised requiring manual intervention.
-This makes it very unlikely that even a clique of seriously
-corrupted NTP servers will result in incorrect time values. In the
-case of embedded computers with no file system, the design
-assumption is that the current era be established from flash memory
-or a clock chip previously set by manual means.</p>
-
-<p>It is essential that any clock synchronization protocol,
-including NTP, include provisions for multiple-server redundancy
-and multiple- route diversity. Past experience has demonstrated the
-wisdom of this approach, which protects clients against hardware
-and software faults, as well as incorrectly operating reference
-sources and sometimes even buggy software. For the most reliable
-service, we recommend multiple reference sources for primary
-servers, including a backup radio or satellite receiver or
-telephone modem. We also recommend that primary servers run NTP
-with other primary servers to provide additional redundancy and
-mutual backup should the reference sources themselves fail or
-operate incorrectly.</p>
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"home"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-<mills@udel.edu></a></address>
-</body>
-</html>
-
projects / thirdparty / ntp.git / commitdiff
