Canadian CHU Radio Modem/Audio Decoder

### CHU Audio/Modem Decoder

#### Synopsis

Address: 127.127.7.u
Reference ID: `CHU`
Driver ID: `CHU`
Serial Port: `/dev/chuu`; 300 baud, 8-bits, no parity
Audio Device: `/dev/audio` and `/dev/audioctl`

#### Description

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 using the `minimuf` and `icom` programs as propagation conditions change throughout the day and night.

This 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.

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-bps modem or modem chip, as described in the Pulse-per-second (PPS) Signal Interfacing page. The driver can be compiled to use this 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 drivers. 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.

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 bps 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.

Format A bursts are sent at seconds 32 through 39 of the minute in hex digits

`6dddhhmmss6dddhhmmss`

The first ten digits encode a frame marker (`6`) followed by the day (`ddd`), hour (`hh` in UTC), minute (`mm`) and the second (`ss`). Since format A bursts are sent during the third decade of seconds the tens digit of `ss` is always 3. The driver uses this to determine correct burst synchronization. These digits are then repeated with the same polarity.

Format B bursts are sent at second 31 of the minute in hex digits

`xdyyyyttaaxdyyyyttaa`

The first ten digits encode a code (`x` described below) followed by the DUT1 (`d` in deciseconds), Gregorian year (`yyyy`), difference TAI - UTC (`tt`) and daylight time indicator (`aa`) peculiar to Canada. These digits are then repeated with inverted polarity.

The `x` is coded

1 Sign of DUT (0 = +)
2 Leap second warning. One second will be added.
4 Leap second warning. One second will be subtracted. This is not likely to happen in our universe.
8 Even parity bit for this nibble.

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 bps, 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 `fudge time1`.

#### Debugging aids

The timecode format used for debugging and data recording includes data helpful in diagnosing problems with the radio signal and serial connections. With debugging enabled (`-d -d -d` on the `ntpd` command line), the driver produces one line for each burst in two formats corresponding to format A and B. Following is format A:

`n b f s m code`

where `n` is the number of characters in the burst (0-11), `b` the burst distance (0-40), `f` the field alignment (-1, 0, 1), `s` the synchronization distance (0-16), `m` the burst number (2-9) and `code` the burst characters as received. Note that the hex digits in each character are reversed, so the burst

`10 38 0 16 9 06851292930685129293`

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.

When the audio driver is compiled, format A is preceded by the gain (0-255) and relative signal level (0-9999). The receiver volume control should be set so that the gain is near the middle of the range 0-255, which results in a signal level near 1000.

Following is format B:

`n b s code`

where `n` is the number of characters in the burst (0-11), `b` the burst distance (0-40), `s` the synchronization distance (0-40) and `code` the burst characters as received. Note that the hex digits in each character are reversed and the last ten digits inverted, so the burst

`11 40 1091891300ef6e76ecff`

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.

In addition to the above, the reference timecode is updated and written to the clockstats file and debug score after the last burst received in the minute. The format is

`qq yyyy ddd hh:mm:ss nn dd tt`

where `qq` are the error flags, as described below, `yyyy` is the year, `ddd` the day, `hh:mm:ss` the time of day, `nn` the number of format A bursts received during the previous minute, `dd` the decoding distance and `tt` the number of timestamps. The error flags are cleared after every update.

For accuracy better than the low milliseconds, the `fudge time1` variable can be used to set the propagation delay and compensate for inherent latencies in the serial port hardware and operating system. This can be done conveniently using the `minimuf` program.

#### Monitor Data

When enabled by the `flag4` fudge flag, every received timecode burst in both format A or format B is written to the `clockstats` file.

#### Fudge Factors

`time1 time`
  Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
`time2 time`
  Not used by this driver.
`stratum number`
  Specifies the driver stratum, in decimal from 0 to 15, with default 0.
`refid string`
  Specifies the driver reference identifier, an ASCII string from one to four characters, with default `CHU`.
`flag1 0 | 1`
  Not used by this driver.
`flag2 0 | 1`
  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.
`flag3 0 | 1`
  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.
`flag4 0 | 1`
  Enable verbose `clockstats` recording if set.

Additional Information

Reference Clock Drivers