Article: 11287 of comp.protocols.time.ntp From: "David L. Mills" Newsgroups: comp.protocols.time.ntp Subject: Re: WWV/H audio drivers and related subjects Date: Thu, 25 Jan 2001 03:35:02 +0000 Organization: University of Delaware, EE/CIS Lab Lines: 123 Message-ID: <3A6F9EE6.8190464F@huey.udel.edu> References: <94a5bn$rrb$1@nnrp.atgi.net> <3a68c78a@news.meer.net> NNTP-Posting-Host: brunce.udel.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dewey.udel.edu 980393779 11354 128.4.2.12 (25 Jan 2001 03:36:19 GMT) X-Complaints-To: usenet@eecis.udel.edu NNTP-Posting-Date: 25 Jan 2001 03:36:19 GMT X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en Path: news.meer.net!nntp1.ba.best.com!news2.best.com!news.maxwell.syr.edu!newsfeed.cwix.com!news.conectiv.net!news.eecis.udel.edu!not-for-mail Xref: news.meer.net comp.protocols.time.ntp:11287 Jeff, Sung to "Sing a song of sixpence" Sing a song of oscillators, Swish and sway they tune. Four and twenty hours the day And never lock too soon. I'm supremely jealous that your Griefkit GC1000 still runs. Mine became dim of LED and finally expired. My particular unit in fact timed the teething Internet for a couple of years, even though it did swish and sway some 100 ms. I checked the WWV/H code to answer your conjectures. The drop-dead watchdog timeout is four days, after which it should blow out the candle and restart from scratch. I checked the WWV/WWVH delay processing but could find nothing wrong. The thing goes to some dreary detail to integrate both the 1000-Hz WWV and 1200-Hz WWVH minute markers and I know that works, since sometimes the H appears instead of the C on the debug trace. Here in Radio-Free Newark, WWVH is heard only intermittently and briefly as the dusk zone skitters across the Pacific circa 03Z-05Z, so I've not been able to test the switching thoroughly. Most of the time we get multipath anyway and the two stations fight each other for the decoder. I expect the driver will be used by folks with dinky Radio Shack shortwave receivers with lousy AGC, no selectivity and low intercept point. So, I made the AGC and demodulator/decoder rather aggressive, which of course raises the false-alarm probability. Yes, it can scrape rare ions from the F layers, but it can sometimes thing bad noise is good ions. The most common of the rare false alarms is when the signal is just coming from the noise and bangs the comb filter outside the jitter gate. Result is a bad frequency sample and eventual derailment. When better radios are available, the likelihood ratio should by raised by notching the thresholds upscale. On the oscillator song, sigh. Again, in cases where signals might not be heard for a day or two, I had to make the radio look healthy, even if that turned out to be a lie. What should happen is the dispersion should ramp up and eventually cause the radio to be deselected if other critters are around to wind the clock. If that doesn't happen, I goofed. Think about it this way. The ultimate oscillator is in Boulder wrangled by a cabal of cesia. Then we get to the codec clock, which is the driver timebase and is wrangled for the ultimate accuracy to the 5-ms matched-filter pulse and comb filter. The performance of the filter ar is truly awesome, but the pulse swishes and sways with the F layer height and ray mode, which for Hawaii could be a couple of milliseconds. Now we get to he system clock itself, which is the ultimate wranglee. It gets nudged by the codec clock, which has a feedback time constant something like several minutes. Maybe that's asking a lot of the codec clock and a large motherboard temperature transient might derail the loop. The question is, when do you believe the received signal, how long do you wait until considering the codec wrangle unhorsed and how long do you wait after that to unhorse the system clock? Dave Jeff Woolsey wrote: > > In article <94a5bn$rrb$1@nnrp.atgi.net>, > Mike P. Storke wrote: > > It's really strange that I've been running NTP all this time and I just now > >discovered the audio drivers for WWV and WWVH. > > I believe they're new in 4.x. I found them this summer. > > > This seems like a great and > >dirt-cheap way of setting up a stratum-1 server, provided a few corrections > >are done. > > >1. Exactly how much CPU horsepower do you need to run this audio driver? > > (I'm running x86 Linux.) > > In my case, up to about 1/3 of a CPU on a SPARCstation 10/612 (60MHz). And > not all the time, either. > > >2. Is this driver really as reliable as the docs state??? I can't help > > remembering that phrase about getting something for nothing... > > Well, let me say this about that. I've been running this driver for > about six months, and it is mostly set-and-forget. However, it has > some quirks and at least one minor bug. > > The bug: The two fudge times cannot be set to different values. time1 > is for WWV, and time2 is for WWVH. I do not live the same distance > from the two stations, so I need two different fudge times. Otherwise > the system wanders about 2ms daily, as compared to a WWVB-derived PPS > signal. > > Quirks: The thing fails far too gracefully. Disconnect WWV audio > input and see how long NTP sychronizes to it. A couple days, in my > experience. The billboard really doesn't provide much indication of > this unless you have other reliable sources; you'll still see a 377 > reach, and the offset will be small, but NTP will be synchronized to > some other source. I'd prefer that the clock become unreachable soon > after audio input is lost and the clock is out of spec. > > Once in a great while it'll synchronize several seconds off. I've > waited a week with good audio input for this to correct itself to no > avail. Restarting ntpd fixed it each time. > > One other thing to say about this driver well illustrates 16 years of > advance in signal processing, both hardware and software. I feed the > driver the audio from a Heathkit GC-1000 clock (which I also use in NTP > and leave at stratum 0 because the audio driver will always outperform > it and NTP will never select the Heathkit for synch) and the GC-1000 is > lately unable to sync to the sound (loose component, I bet, come to > think of it) while the audio driver is updating continuously. > > >3. And most importantly, if any of you are using this driver, what's your > > favorite method of compensating for the total system delay between the > > transmitters and the point where the driver delivers the goods to the > > NTP daemon? That is, compensating for the combination of propagation > > delay (which will vary by a small amount during the day and season, of > > course) and processing delay in the DSP engine. > > Use a large ( >10 ) number of nearby stratum-1 clocks and see how far off > you are from their average; fudge to that. Can't do much about the daily > variations, unless you're into having cron reset the fudge factor several > times per day. > Article: 11273 of comp.protocols.time.ntp From: "David L. Mills" Newsgroups: comp.protocols.time.ntp Subject: Re: WWV/H audio drivers and related subjects Date: Thu, 25 Jan 2001 00:34:31 +0000 Organization: University of Delaware, EE/CIS Lab Lines: 56 Message-ID: <3A6F7497.773B482D@huey.udel.edu> References: <94a5bn$rrb$1@nnrp.atgi.net> NNTP-Posting-Host: brunce.udel.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dewey.udel.edu 980382943 27145 128.4.2.12 (25 Jan 2001 00:35:43 GMT) X-Complaints-To: usenet@eecis.udel.edu NNTP-Posting-Date: 25 Jan 2001 00:35:43 GMT X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en Path: news.meer.net!nntp1.ba.best.com!news2.best.com!news.maxwell.syr.edu!newsfeed.cwix.com!news.conectiv.net!news.eecis.udel.edu!not-for-mail Xref: news.meer.net comp.protocols.time.ntp:11273 Mike, The audio drivers consume 40% of a SPARC IPC, 6% of an UltraSPARC-1 and in the noise on an UltraSPARC-2. So far as I know, the stuff has not been verified in Linux and/or FreeBSD. If so, I would very much like to hear about it. Depending on the part of the country you raise antenna in, you may find one of the WWV, WWVH or CHU drivers most useful. Here in Delaware and with a frequency-agile receiver, the drivers lock to CHU 24/7 and WWV mostly 24/7 depending on the ions. For a fixed-frequency receiver the WWV driver locks most of the day (15 MHz here) or most of the night (5 MHz in winter), but not both. You really don't need anything fancy to calibrate the propagation delay. There are lots of freebie programs that do that or you can eyeball-and-map and calculate it yourself. I used a calibrated cesium clock to check the performance and processing delays here. The measured filter delays are in the documentation. There is a technical report linked from www.eecis.udel.edu/~mills/resource.htm. It is on the DSP93 implementation, but the audio driver uses many of the same algorithms. It has lots of graphs showing typical performance. Dave from "Mike P. Storke" wrote: > > It's really strange that I've been running NTP all this time and I just now > discovered the audio drivers for WWV and WWVH. This seems like a great and > dirt-cheap way of setting up a stratum-1 server, provided a few corrections > are done. I tried to contact NIST Boulder, but they were no help except to > say that I should post my questions here, so here goes: > > 1. Exactly how much CPU horsepower do you need to run this audio driver? > (I'm running x86 Linux.) > 2. Is this driver really as reliable as the docs state??? I can't help > remembering that phrase about getting something for nothing... > 3. And most importantly, if any of you are using this driver, what's your > favorite method of compensating for the total system delay between the > transmitters and the point where the driver delivers the goods to the > NTP daemon? That is, compensating for the combination of propagation > delay (which will vary by a small amount during the day and season, of > course) and processing delay in the DSP engine. > > One other question: now that the guy at www.gpsclock.com has stopped > selling his GPS timing receiver, are there any other dirt cheap GPS timing > receivers left out there? Ditto for WWVB (receivers seem to be proliferating > now that they've finished the transmitter upgrades, but not a whole lot > have outputs and those that do are, I hear, flaky at best) and maybe even > the GOES timecode. > > Thanks!! > > Mike