summaryrefslogtreecommitdiffstats
path: root/contrib/ntp/html/driver7.htm
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/ntp/html/driver7.htm')
-rw-r--r--contrib/ntp/html/driver7.htm834
1 files changed, 450 insertions, 384 deletions
diff --git a/contrib/ntp/html/driver7.htm b/contrib/ntp/html/driver7.htm
index 5995072..029ac04 100644
--- a/contrib/ntp/html/driver7.htm
+++ b/contrib/ntp/html/driver7.htm
@@ -1,362 +1,397 @@
-<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>; 9600 baud, 8-bits, no parity
-<br>Audio Device: <tt>/dev/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>
-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>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>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.
+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>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.
+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.
+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>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.
+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.
+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>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.
+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.
+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.
+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. 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.
+<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>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 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.
+(<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>
-<dt><tt>1</tt>
-<dd>Sign of DUT (0 = +)/dd>
+<dd>Sign of DUT (0 = +)/dd&gt;</dd>
+
+<dt><tt>2</tt></dt>
-<dt><tt>2</tt>
<dd>Leap second warning. One second will be added.</dd>
-<dt><tt>4</tt>
+<dt><tt>4</tt></dt>
+
<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>
+<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.
+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>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.
+<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.
+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
@@ -380,84 +415,103 @@ is written to the <tt>clockstats</tt> file in the following format:
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
+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>
-<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>
+<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:
+<dt><tt>q</tt></dt>
+
+<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>
+
+<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>4</tt></dt>
+
+<dd>Timestamp alarm. Fewer than 20 timestamps have been
+determined.</dd>
+
+<dt><tt>2</tt></dt>
-<dt><tt>2</tt>
<dd>Format alarm. The majority timecode contains invalid bit
combinations.</dd>
-<dt><tt>1</tt>
+<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>
-<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>
+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>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>rfrq</tt></dt>
+
+<dd>The current radio frequency, if the CI-V interface is active,
+or 'X' if not.</dd>
+
+<dt><tt>bcnt</tt></dt>
+
+<dd>The number of format A bursts received during the most recent
+minute bursts were received.</dd>
+
+<dt><tt>dist</tt></dt>
+
<dd>The minimum decoding distance determined during the most recent
minute bursts were received.</dd>
-<dt><tt>tsmp</tt>
+<dt><tt>tsmp</tt></dt>
+
<dd>The number of timestamps determined during the most recent
minute bursts were received.</dd>
</dl>
@@ -465,12 +519,11 @@ minute bursts were received.</dd>
<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>
@@ -542,50 +595,63 @@ known radios.
<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>
+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>
-<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>
+<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
+&lt;mills@udel.edu&gt;</a></address>
+</body>
+</html>
+
OpenPOWER on IntegriCloud