diff options
Diffstat (limited to 'html/audio.htm')
| -rw-r--r-- | html/audio.htm | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/html/audio.htm b/html/audio.htm new file mode 100644 index 0000000..b345bc7 --- /dev/null +++ b/html/audio.htm @@ -0,0 +1,187 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> +<html> +<head> +<meta name="generator" content="HTML Tidy, see www.w3.org"> +<title>Reference Clock Audio Drivers</title> +</head> +<body> +<h3>Reference Clock Audio Drivers</h3> + +<img align="left" src="pic/radio2.jpg" alt="gif"> + +<p>Make a little noise here.<br clear="left"> +</p> + +<hr> +<p>There are some applications in which the computer time can be +disciplined to an audio signal, rather than a serial timecode and +communications port or special purpose bus peripheral. This is +useful in such cases where the audio signal is sent over a +telephone circuit, for example, or received directly from a +shortwave receiver. In such cases the audio signal can be connected +via an ordinary sound card or baseboard audio codec. The suite of +NTP reference clock drivers currently includes three drivers +suitable for these applications. They include a driver for the +Inter Range Instrumentation Group (IRIG) signals produced by most +radio clocks and timing devices, another for the Canadian +time/frequency radio station CHU and a third for the NIST +time/frequency radio stations WWV and WWVH. The radio drivers are +designed to work with ordinary inexpensive shortwave radios and may +be one of the least expensive ways to build a good primary time +server.</p> + +<p>All three drivers make ample use of sophisticated digital signal +processing algorithms designed to efficiently extract timing +signals from noise and interference. The radio station drivers in +particular implement optimum linear demodulation and decoding +techniques, including maximum likelihood and soft-decision methods. +The documentation page for each driver contains an in-depth +discussion on the algorithms and performance expectations. In some +cases the algorithms are further analyzed, modelled and evaluated +in a technical report.</p> + +<p>Currently, the audio drivers are compatible with Sun operating +systems, including Solaris and SunOS, and the native audio codec +interface supported by these systems. In fact, the interface is +quite generic and support for other systems, in particular the +various Unix generics, should not be difficult. Volunteers are +solicited.</p> + +<p>The audio drivers include a number of common features designed +to groom input signals, suppress spikes and normalize signal +levels. An automatic gain control (AGC) feature provides protection +against overdriven or underdriven input signals. It is designed to +maintain adequate demodulator signal amplitude while avoiding +occasional noise spikes. In order to assure reliable operation, the +signal level must be in the range where the audio gain control is +effective. In general, this means the input signal level must be +such as to cause the AGC to set the gain somewhere in the middle of +the range from 0 to 255, as indicated in the timecode displayed by +the <tt>ntpq</tt> program.</p> + +<p>The drivers operate by disciplining a logical clock based on the +codec sample clock to the audio signal as received. This is done by +stuffing or slipping samples as required to maintain exact +frequency to the order of 0.1 PPM. In order for the driver to +reliably lock on the audio signal, the sample clock frequency +tolerance must be less than 250 PPM (.025 percent) for the IRIG +driver and half that for the radio drivers. The largest error +observed so far is about 60 PPM, but it is possible some sound +cards or codecs may exceed that value.</p> + +<p>The drivers include provisions to select the input port and to +monitor the input signal. The <tt>fudge flag 2</tt> selects the +microphone port if set to zero or the line-in port if set to one. +It does not seem useful to specify the compact disc player port. +The <tt>fudge flag 3</tt> enables the input signal monitor using +the previously selected output port and output gain. Both of these +flags can be set in the configuration file or remotely using the +<tt>ntpdc</tt> utility program.</p> + +<h4>Shortwave Radio Drivers</h4> + +<p>The WWV/H and CHU audio drivers require an external shortwave +radio with the radio output - speaker or headphone jack - connected +to either the microphone or line-in port on the computer. There is +some degree of art in setting up the radio and antenna and getting +the setup to work. While the drivers are highly sophisticated and +efficient in extracting timing signals from noise and interference, +it always helps to have as clear a signal as possible.</p> + +<p>The most important factor affecting the radio signal is the +antenna. It need not be long - even 15 feet is enough if it is +located outside of a metal frame building, preferably on the roof, +and away from metallic objects. An ordinary CB whip mounted on a +PVC pipe and wooden X-frame on the roof should work well with most +portable radios, as they are optimized for small antennas.</p> + +<p>The radio need not be located near the computer; in fact, it +generally works better if the radio is outside the near field of +computers and other electromagnetic noisemakers. It can be in the +elevator penthouse connected by house wiring, which can also be +used to power the radio. A couple of center-tapped audio +transformers will minimize noise pickup and provide phantom power +to the radio with return via the AC neutral wire.</p> + +<p>The WWV/H and CHU transmitters operate on several frequencies +simultaneously, so that in most parts of North America at least one +frequency supports propagation to the receiver location at any +given hour. While both drivers support the ICOM CI-V radio +interface and can tune the radio automatically, computer-tunable +radios are expensive and probably not cost effective compared to a +GPS receiver. So, the radio frequency must usually be fixed and +chosen by compromise.</p> + +<p>Shortwave (3-30 MHz) radio propagation phenomena are well known +to shortwave enthusiasts. The phenomena generally obey the +following rules:</p> + +<ul> +<li>The optimum frequency is higher in daytime than nighttime, +stays high longer on summer days and low longer on winter +nights.</li> + +<li>Transitions between daytime and nightime conditions generally +occur somewhat after sunrise and sunset at the midpoint of the path +from transmitter to receiver.</li> + +<li>Ambient noise (static) on the lower frequencies follows the +thunderstorm season, so is higher on summer afternoons and +evenings.</li> + +<li>The lower frequency bands are best for shorter distances, while +the higher bands are best for longer distances.</li> + +<li>The optimum frequencies are higher at the peak of the 11-year +sunspot cycle and lower at the trough. The current sunspot cycle +should peak in the first couple of years beginning the +century.</li> +</ul> + +The best way to choose a frequency is to listen at various times +over the day and determine the best highest (daytime) and lowest +(nighttime) frequencies. Then, assuming one is available, choose +the highest frequency between these frequencies. This strategy +assumes that the high frequency is more problematic than the low, +that the low frequency probably comes with severe multipath and +static, and insures that probably twice a day the chosen frequency +will work. For instance, on the east coast the best compromise CHU +frequency is probably 7335 kHz and the best WWV frequency is +probably 15 MHz. + +<h4>Debugging Aids</h4> + +<p>The audio drivers include extensive debugging support to help +hook up the audio signals and monitor the driver operations. The +documentation page for each driver describes the various messages +that can be produced either in real-time or written to the <tt> +clockstats</tt> file for later analysis. Of particular help in +verifying signal connections and compatibility is a provision to +monitor the signal via headphones or speaker.</p> + +<p>The drivers write a synthesized timecode to the <tt> +clockstats</tt> file each time the clock is set or verified and at +other times if verbose monitoring is enabled. The format includes +several fixed-length fields defining the Gregorian time to the +millisecond, together with additional variable-length fields +specific to each driver. The data include the intervals since the +clock was last set or verified, the audio gain and various state +variables and counters specific to each driver.</p> + +<h4>Additional Information</h4> + +<a href="refclock.htm">Reference Clock Drivers</a> <br> +<a href="driver7.htm">Radio CHU Audio Demodulator/Decoder</a> <br> +<a href="driver36.htm">Radio WWV/H Audio Demodulator/Decoder</a> +<br> +<a href="driver6.htm">IRIG Audio Decoder</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 +<mills@udel.edu></a></address> +</body> +</html> + |
