235 lines
26 KiB
HTML
235 lines
26 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
|
||
|
|
<html>
|
||
|
|
|
||
|
|
<head>
|
||
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
||
|
|
<title>Radio CHU Audio Demodulator/Decoder</title>
|
||
|
|
<link href="../scripts/style.css" type="text/css" rel="stylesheet">
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body>
|
||
|
|
<h3>Radio CHU Audio Demodulator/Decoder</h3>
|
||
|
|
<h4>Related Links</h4>
|
||
|
|
<script type="text/javascript" language="javascript" src="../scripts/links8.txt"></script>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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 on the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</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 or line input port.</p>
|
||
|
|
<p>This driver incorporates several features in common with other audio drivers such as described in the <a href="driver36.html">Radio WWV/H Audio Demodulator/Decoder</a> and the <a href="driver6.html">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.html">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>
|
||
|
|
<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.</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>
|
||
|
|
<p>Format A bursts are sent at seconds 32 through 39 of the minute in hex digits</p>
|
||
|
|
<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>
|
||
|
|
<p>Format B bursts are sent at second 31 of the minute in hex digits</p>
|
||
|
|
<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>
|
||
|
|
<p>The <tt>x</tt> is coded</p>
|
||
|
|
<dl>
|
||
|
|
<dt><tt>1</tt>
|
||
|
|
<dd>Sign of DUT (0 = +)/dd>
|
||
|
|
<dt><tt>2</tt>
|
||
|
|
<dd>Leap second warning. One second will be added.
|
||
|
|
<dt><tt>4</tt>
|
||
|
|
<dd>Leap second warning. One second will be subtracted. This is not likely to happen in our universe.
|
||
|
|
<dt><tt>8</tt>
|
||
|
|
<dd>Even parity bit for this nibble.
|
||
|
|
</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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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>
|
||
|
|
<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.
|
||
|
|
<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.
|
||
|
|
<dt><tt>4</tt>
|
||
|
|
<dd>Timestamp alarm. Fewer than 20 timestamps have been determined.
|
||
|
|
<dt><tt>2</tt>
|
||
|
|
<dd>Format alarm. The majority timecode contains invalid bit combinations.
|
||
|
|
<dt><tt>1</tt>
|
||
|
|
<dd>Frame alarm. A framing or format error occurred on at least one burst during the minute.
|
||
|
|
</dl>
|
||
|
|
<p>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.</p>
|
||
|
|
<dt><tt>yyyy ddd hh:mm:ss.fff</tt>
|
||
|
|
<dd>The timecode format itself is self explanatory. Note that the Gregorian year is decoded directly from the transmitted timecode.
|
||
|
|
<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.
|
||
|
|
<dt><tt>d</tt>
|
||
|
|
<dd>The DST code for Canada encodes the state for all provinces.
|
||
|
|
<dt><tt>dut</tt>
|
||
|
|
<dd>The DUT sign and magnitude shows the current UT1 offset relative to the displayed UTC time, in deciseconds.
|
||
|
|
<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.
|
||
|
|
<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.
|
||
|
|
<dt><tt>bcnt</tt>
|
||
|
|
<dd>The number of format A bursts received during the most recent minute bursts were received.
|
||
|
|
<dt><tt>dist</tt>
|
||
|
|
<dd>The minimum decoding distance determined during the most recent minute bursts were received.
|
||
|
|
<dt><tt>tsmp</tt>
|
||
|
|
<dd>The number of timestamps determined during the most recent minute bursts were received.
|
||
|
|
</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 width="100%" cols="6">
|
||
|
|
<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>
|
||
|
|
<dd>Specifies the propagation delay for CHU (45:18N 75:45N), in seconds and fraction, with default 0.0.
|
||
|
|
<dt><tt>time2 <i>time</i></tt>
|
||
|
|
<dd>Not used by this driver.
|
||
|
|
<dt><tt>stratum <i>number</i></tt>
|
||
|
|
<dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
|
||
|
|
<dt><tt>refid <i>string</i></tt>
|
||
|
|
<dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>CHU</tt>.
|
||
|
|
<dt><tt>flag1 0 | 1</tt>
|
||
|
|
<dd>Not used by this driver.
|
||
|
|
<dt><tt>flag2 0 | 1</tt>
|
||
|
|
<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.
|
||
|
|
<dt><tt>flag3 0 | 1</tt>
|
||
|
|
<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.
|
||
|
|
<dt><tt>flag4 0 | 1</tt>
|
||
|
|
<dd>Enable verbose <tt>clockstats</tt> recording if set.
|
||
|
|
</dl>
|
||
|
|
<hr>
|
||
|
|
<script type="text/javascript" language="javascript" src="../scripts/footer.txt"></script>
|
||
|
|
</body>
|
||
|
|
|
||
|
|
</html>
|