freebsd-dev/contrib/ntp/html/driver7.htm

592 lines
24 KiB
HTML
Raw Normal View History

2000-01-28 14:55:50 +00:00
<html><head><title>
Radio CHU Audio Demodulator/Decoder
</title></head><body><h3>
Radio CHU Audio Demodulator/Decoder
</h3><hr>
<h4>Synopsis</h4>
1999-12-09 13:01:21 +00:00
Address: 127.127.7.<I>u</I>
2000-01-28 14:55:50 +00:00
<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>; 9600 baud, 8-bits, no parity
<br>Audio Device: <tt>/dev/audio</tt> and <tt>/dev/audioctl</tt>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
<h4>Description</h4>
This driver synchronizes the computer time using data encoded in radio
transmissions from Canadian time/frequency station CHU in Ottawa,
Ontario. 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
1999-12-09 13:01:21 +00:00
but effective receiver/demodulator can be constructed from an ordinary
2000-01-28 14:55:50 +00:00
shortwave receiver and Bell 103 compatible, 300-b/s modem or modem chip,
as described in the <a href=pps.htm>Pulse-per-second (PPS) Signal
Interfacing</a> page. The driver can be compiled to use a modem to
receive the radio signal and demodulate the data. Alternatively, the
driver can be compiled to use the audio codec of the Sun workstation or
another with compatible audio interface. In the latter case, the driver
1999-12-09 13:01:21 +00:00
implements the modem using DSP routines, so the radio can be connected
directly to either the microphone on line input port.
2000-01-28 14:55:50 +00:00
<p>The driver replaces an earlier one built by Dennis Ferguson in 1988.
The earlier driver required a special line discipline which preprocessed
the signal in order to improve accuracy and avoid errors. The new driver
includes more powerful algorithms implemented directly in the driver and
requires no line discipline. It decodes the data using a
maximum-likelihood technique which exploits the considerable degree of
redundancy available to maximize accuracy and minimize errors.
<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 take advantage of all the redundancy
available in each broadcast message or burst. In each burst described in
the next section, 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 will be set to the correct 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.
<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.
<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. A missing <tt>mode</tt>
keyword or a zero argument leaves the interface disabled. 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.
<p>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.
<h4>Radio Broadcast Format</h4>
<p>The CHU time broadcast includes an audio signal compatible with the
1999-12-09 13:01:21 +00:00
Bell 103 modem standard (mark = 2225 Hz, space = 2025 Hz). It consist of
2000-01-28 14:55:50 +00:00
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>Format A bursts are sent at seconds 32 through 39 of the minute in
hex digits
<p><tt>6dddhhmmss6dddhhmmss</tt>
<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>Format B bursts are sent at second 31 of the minute in hex digits
<p><tt>xdyyyyttaaxdyyyyttaa</tt>
<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 <tt>x</tt> is coded
<dl>
<dt><tt>1</tt>
<dd>Sign of DUT (0 = +)/dd>
<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>8</tt>
<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.
<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>With debugging enabled the driver produces messages in the following
formats:
<p>A format <tt>chuA</tt> message is produced for each format A burst
received in seconds 32 through 39 of the minute:
<p><tt>chuA n b s code</tt>
<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><tt>11 40 1091891300ef6e76ecff</tt>
<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>A format <tt>chuB</tt> message is produced for each format B burst
received in second 31 of the minute:
<p><tt>chuB n b f s m code</tt>
<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><tt>10 38 0 16 9 06851292930685129293</tt>
<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>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.
<h4>Monitor Data</h4>
When enabled by the <tt>filegen</tt> facility, every received timecode
is written to the <tt>clockstats</tt> file in the following format:
<pre>
sq yy ddd hh:mm:ss.fff ld dut lset agc rfrq bcnt dist tsmp
s sync indicator
q quality character
yyyy Gregorian year
ddd day of year
hh hour of day
mm minute of hour
ss second of minute
fff millisecond of second
l leap second warning
d DST state
dut DUT sign and magnitude in deciseconds
lset minutes since last set
agc audio gain (0-255)
rfrq radio frequency
bcnt burst count
dist decoding distance
tsmp timestamps captured
</pre>
The fields beginning with <tt>year</tt> and extending through
<tt>dut</tt> are decoded from the received data and are in fixed-length
format. The <tt>agc</tt> and <tt>lset</tt> fields, as well as the
following driver-dependent fields, are in variable-length format.
<dl>
<dt><tt>s</tt>
<dd>The sync indicator is initially <tt>?</tt> before the clock is set,
but turns to space when the clock is correctly set.</dd>
<dt><tt>q</tt>
<dd>The quality character is a four-bit hexadecimal code showing which
alarms have been raised during the most recent minute. Each bit is
associated with a specific alarm condition according to the following:
<dl>
<dt><tt>8</tt>
<dd>Decoder alarm. A majority of repetitions for at least one digit of
the timecode fails to agree.
</dd>
<dt><tt>4</tt>
<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.</dd>
<dt><tt>2</tt>
<dd>Format alarm. The majority timecode contains invalid bit
combinations.</dd>
<dt><tt>1</tt>
<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.
<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>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>d</tt>
<dd>The DST code for Canada encodes the state for all provinces.</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 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>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>rfrq</tt>
<dd>The current radio frequency, if the CI-V interface is active, or 'X'
if not.</dd>
<dt><tt>bcnt</tt>
<dd>The number of format A bursts received 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>
<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%>
<tr>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
<td>Radio</td>
<td>Hex</td>
<td>Decimal</td>
</tr>
<tr>
<td>IC725</td>
<td>0x28</td>
<td>40</td>
<td>IC781</td>
<td>0x26</td>
<td>38</td>
</tr>
<tr>
<td>IC726</td>
<td>0x30</td>
<td>48</td>
<td>R7000</td>
<td>0x08</td>
<td>8</td>
</tr>
<tr>
<td>IC735</td>
<td>0x04</td>
<td>4</td>
<td>R71</td>
<td>0x1A</td>
<td>26</td>
</tr>
<tr>
<td>IC751</td>
<td>0x1c</td>
<td>28</td>
<td>R7100</td>
<td>0x34</td>
<td>52</td>
</tr>
<tr>
<td>IC761</td>
<td>0x1e</td>
<td>30</td>
<td>R72</td>
<td>0x32</td>
<td>50</td>
</tr>
<tr>
<td>IC765</td>
<td>0x2c</td>
<td>44</td>
<td>R8500</td>
<td>0x4a</td>
<td>74</td>
</tr>
<tr>
<td>IC775</td>
<td>0x46</td>
<td>68</td>
<td>R9000</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>time2 <I>time</I></tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>stratum <I>number</I></tt></dt>
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default
0.</dd>
<dt><tt>refid <I>string</I></tt></dt>
<dd>Specifies the driver reference identifier, an ASCII string from one
to four characters, with default <tt>CHU</tt>.</dd>
<dt><tt>flag1 0 | 1</tt></dt>
<dd>Not used by this driver.</dd>
<dt><tt>flag2 0 | 1</tt></dt>
<dd>When the audio driver is compiled, this flag selects the audio input
1999-12-09 13:01:21 +00:00
port, where 0 is the mike port (default) and 1 is the line-in port. It
2000-01-28 14:55:50 +00:00
does not seem useful to select the compact disc player port.</dd>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
<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>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
<dt><tt>flag4 0 | 1</tt></dt>
<dd>Enable verbose <tt>clockstats</tt> recording if set.</dd>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
</dl>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
<h4>Additional Information</h4>
<A HREF="refclock.htm">Reference Clock Drivers</A>
<br><A HREF="audio.htm">Reference Clock Audio Drivers</A>
1999-12-09 13:01:21 +00:00
2000-01-28 14:55:50 +00:00
<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
</address></a></body></html>