contrib/ntp/html/audio.htm

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
   2 <html>
   3 <head>
   4 <meta name="generator" content="HTML Tidy, see www.w3.org">
   5 <title>Reference Clock Audio Drivers</title>
   6 </head>
   7 <body>
   8 <h3>Reference Clock Audio Drivers</h3>
   9
  10 <img align="left" src="pic/radio2.jpg" alt="gif">
  11
  12 <p>Make a little noise here.<br clear="left">
  13 </p>
  14
  15 <hr>
  16 <p>There are some applications in which the computer time can be
  17 disciplined to an audio signal, rather than a serial timecode and
  18 communications port or special purpose bus peripheral. This is
  19 useful in such cases where the audio signal is sent over a
  20 telephone circuit, for example, or received directly from a
  21 shortwave receiver. In such cases the audio signal can be connected
  22 via an ordinary sound card or baseboard audio codec. The suite of
  23 NTP reference clock drivers currently includes three drivers
  24 suitable for these applications. They include a driver for the
  25 Inter Range Instrumentation Group (IRIG) signals produced by most
  26 radio clocks and timing devices, another for the Canadian
  27 time/frequency radio station CHU and a third for the NIST
  28 time/frequency radio stations WWV and WWVH. The radio drivers are
  29 designed to work with ordinary inexpensive shortwave radios and may
  30 be one of the least expensive ways to build a good primary time
  31 server.</p>
  32
  33 <p>All three drivers make ample use of sophisticated digital signal
  34 processing algorithms designed to efficiently extract timing
  35 signals from noise and interference. The radio station drivers in
  36 particular implement optimum linear demodulation and decoding
  37 techniques, including maximum likelihood and soft-decision methods.
  38 The documentation page for each driver contains an in-depth
  39 discussion on the algorithms and performance expectations. In some
  40 cases the algorithms are further analyzed, modelled and evaluated
  41 in a technical report.</p>
  42
  43 <p>Currently, the audio drivers are compatible with Sun operating
  44 systems, including Solaris and SunOS, and the native audio codec
  45 interface supported by these systems. In fact, the interface is
  46 quite generic and support for other systems, in particular the
  47 various Unix generics, should not be difficult. Volunteers are
  48 solicited.</p>
  49
  50 <p>The audio drivers include a number of common features designed
  51 to groom input signals, suppress spikes and normalize signal
  52 levels. An automatic gain control (AGC) feature provides protection
  53 against overdriven or underdriven input signals. It is designed to
  54 maintain adequate demodulator signal amplitude while avoiding
  55 occasional noise spikes. In order to assure reliable operation, the
  56 signal level must be in the range where the audio gain control is
  57 effective. In general, this means the input signal level must be
  58 such as to cause the AGC to set the gain somewhere in the middle of
  59 the range from 0 to 255, as indicated in the timecode displayed by
  60 the <tt>ntpq</tt> program.</p>
  61
  62 <p>The drivers operate by disciplining a logical clock based on the
  63 codec sample clock to the audio signal as received. This is done by
  64 stuffing or slipping samples as required to maintain exact
  65 frequency to the order of 0.1 PPM. In order for the driver to
  66 reliably lock on the audio signal, the sample clock frequency
  67 tolerance must be less than 250 PPM (.025 percent) for the IRIG
  68 driver and half that for the radio drivers. The largest error
  69 observed so far is about 60 PPM, but it is possible some sound
  70 cards or codecs may exceed that value.</p>
  71
  72 <p>The drivers include provisions to select the input port and to
  73 monitor the input signal. The <tt>fudge flag 2</tt> selects the
  74 microphone port if set to zero or the line-in port if set to one.
  75 It does not seem useful to specify the compact disc player port.
  76 The <tt>fudge flag 3</tt> enables the input signal monitor using
  77 the previously selected output port and output gain. Both of these
  78 flags can be set in the configuration file or remotely using the
  79 <tt>ntpdc</tt> utility program.</p>
  80
  81 <h4>Shortwave Radio Drivers</h4>
  82
  83 <p>The WWV/H and CHU audio drivers require an external shortwave
  84 radio with the radio output - speaker or headphone jack - connected
  85 to either the microphone or line-in port on the computer. There is
  86 some degree of art in setting up the radio and antenna and getting
  87 the setup to work. While the drivers are highly sophisticated and
  88 efficient in extracting timing signals from noise and interference,
  89 it always helps to have as clear a signal as possible.</p>
  90
  91 <p>The most important factor affecting the radio signal is the
  92 antenna. It need not be long - even 15 feet is enough if it is
  93 located outside of a metal frame building, preferably on the roof,
  94 and away from metallic objects. An ordinary CB whip mounted on a
  95 PVC pipe and wooden X-frame on the roof should work well with most
  96 portable radios, as they are optimized for small antennas.</p>
  97
  98 <p>The radio need not be located near the computer; in fact, it
  99 generally works better if the radio is outside the near field of
 100 computers and other electromagnetic noisemakers. It can be in the
 101 elevator penthouse connected by house wiring, which can also be
 102 used to power the radio. A couple of center-tapped audio
 103 transformers will minimize noise pickup and provide phantom power
 104 to the radio with return via the AC neutral wire.</p>
 105
 106 <p>The WWV/H and CHU transmitters operate on several frequencies
 107 simultaneously, so that in most parts of North America at least one
 108 frequency supports propagation to the receiver location at any
 109 given hour. While both drivers support the ICOM CI-V radio
 110 interface and can tune the radio automatically, computer-tunable
 111 radios are expensive and probably not cost effective compared to a
 112 GPS receiver. So, the radio frequency must usually be fixed and
 113 chosen by compromise.</p>
 114
 115 <p>Shortwave (3-30 MHz) radio propagation phenomena are well known
 116 to shortwave enthusiasts. The phenomena generally obey the
 117 following rules:</p>
 118
 119 <ul>
 120 <li>The optimum frequency is higher in daytime than nighttime,
 121 stays high longer on summer days and low longer on winter
 122 nights.</li>
 123
 124 <li>Transitions between daytime and nightime conditions generally
 125 occur somewhat after sunrise and sunset at the midpoint of the path
 126 from transmitter to receiver.</li>
 127
 128 <li>Ambient noise (static) on the lower frequencies follows the
 129 thunderstorm season, so is higher on summer afternoons and
 130 evenings.</li>
 131
 132 <li>The lower frequency bands are best for shorter distances, while
 133 the higher bands are best for longer distances.</li>
 134
 135 <li>The optimum frequencies are higher at the peak of the 11-year
 136 sunspot cycle and lower at the trough. The current sunspot cycle
 137 should peak in the first couple of years beginning the
 138 century.</li>
 139 </ul>
 140
 141 The best way to choose a frequency is to listen at various times
 142 over the day and determine the best highest (daytime) and lowest
 143 (nighttime) frequencies. Then, assuming one is available, choose
 144 the highest frequency between these frequencies. This strategy
 145 assumes that the high frequency is more problematic than the low,
 146 that the low frequency probably comes with severe multipath and
 147 static, and insures that probably twice a day the chosen frequency
 148 will work. For instance, on the east coast the best compromise CHU
 149 frequency is probably 7335 kHz and the best WWV frequency is
 150 probably 15 MHz.
 151
 152 <h4>Debugging Aids</h4>
 153
 154 <p>The audio drivers include extensive debugging support to help
 155 hook up the audio signals and monitor the driver operations. The
 156 documentation page for each driver describes the various messages
 157 that can be produced either in real-time or written to the <tt>
 158 clockstats</tt> file for later analysis. Of particular help in
 159 verifying signal connections and compatibility is a provision to
 160 monitor the signal via headphones or speaker.</p>
 161
 162 <p>The drivers write a synthesized timecode to the <tt>
 163 clockstats</tt> file each time the clock is set or verified and at
 164 other times if verbose monitoring is enabled. The format includes
 165 several fixed-length fields defining the Gregorian time to the
 166 millisecond, together with additional variable-length fields
 167 specific to each driver. The data include the intervals since the
 168 clock was last set or verified, the audio gain and various state
 169 variables and counters specific to each driver.</p>
 170
 171 <h4>Additional Information</h4>
 172
 173 <a href="refclock.htm">Reference Clock Drivers</a> <br>
 174 <a href="driver7.htm">Radio CHU Audio Demodulator/Decoder</a> <br>
 175 <a href="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</a>
 176 <br>
 177 <a href="driver6.htm">IRIG Audio Decoder</a>
 178
 179 <hr>
 180 <a href="index.htm"><img align="left" src="pic/home.gif" alt=
 181 "gif"></a>
 182
 183 <address><a href="mailto:mills@udel.edu">David L. Mills
 184 &lt;mills@udel.edu&gt;</a></address>
 185 </body>
 186 </html>
 187