source: trunk/third/xntp/html/audio.htm @ 17260

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