592 lines
24 KiB
HTML
592 lines
24 KiB
HTML
<html><head><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>; 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 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
|
|
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=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
|
|
implements the modem using DSP routines, so the radio can be connected
|
|
directly to either the microphone on line input port.
|
|
|
|
<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
|
|
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>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
|
|
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>
|
|
|
|
<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>
|