[ntp:questions] Re: Jonathan Buzzard's radioclkd and FreeBSD

Jonathan Buzzard jonathan at uk.me.buzzard
Sun Nov 9 22:42:57 UTC 2003


In article <Fn0rD at nospam.news.nospam.dyndns.dk>,
	Barry Bouwsma <ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> writes:

[SNIP]
> 
> I added a few sanity checks, plus auto-polarity detection for DCF,
> but spurious pulses had never been a serious problem for me, though
> I'm not as far removed from Mainflingen as you are.  Whether the
> auto-polarity detection might also work for other than 100/200msec
> signals, I haven't looked at the other clock pulse formats to guess.

Again I would be interested to see these patches. If I can work
the ideas into the code so it works for other clocks as well it
improves the program. Plus the JJY signal uses opposite polarity
to the MSF60 and WWVB signals.


> One other change I made to ntpd because of the radioclk program and/or
> the GENERIC driver, was to be more tolerant of wildly-off time data,
> and instead of exiting when it decides to trust a jump of, say, 3600
> seconds (often seen induced by lightning), it continues running in
> hopes the next data will be better.  This has saved me several times
> when ntpd would have bailed needlessly.

What I think we should do here is that the radioclkd program should
check the time decoded against what it expects it should get, and
not pass on insane values to NTPD. Something like last good signal
two minutes ago was X, but this apparently good singal is X+123min,
must be a load of rubbish, ignore. Currenty it only rejects times more
than 1000 secs from the system time, and the above (which has just
come to me) seems to be a worthwhile extra sanity check.

> I also added PPS updating of the shared memory segment, greatly
> reducing the jitter, and allowing ntpd to use accurate time data
> at minpoll of 16 seconds, plus whichever option nabs several samples
> to smooth the data.

Since the 0.7 version you are using I added a PPS averaging feature.
When locked into a clock, it takes the closest 30 second offests
for a minute and then passes the median of these offsets to ntpd.
This gave an order of magnitude improvement in jitter times.

When I get time I will start another unstable branch to work on
the following new features (in no particular order)

 1. JJY decoding, as I now have a near complete translation of the
    time format from the web page.
 2. HGB decoding, i.e. take account of the extra funnies on the hour
    in an otherwise DCF time code. It should just work out the box
    with DCF but will barf on some of the hours I think. Need a 75kHz
    crystal to modify a DCF receiver to test.
 3. Use the PPS API where possible for improved accuracy.
 4. Pulse filtering for improved tolerance of noisy signals.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Northumberland, United Kingdom.       Tel: +44 1661-832195



More information about the questions mailing list