[ntp:questions] Re: distance to dcf77 transmitter: how to set the fudge?
ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Fri Jan 28 11:00:55 UTC 2005
On 27 Jan 2005 00:59:32 -0800, Paul Croome wrote:
> > Am I right that when I want to tell ntpd that it has to take care of the
> > distance to the dcf77 transmitter that I have to do that like this?
> Yes, in principle you're right. But in my experience, the precision of the
> DCF77 signal together with a low-cost receiver is of the order of a few
In addition, the variance between several different (cheap) hardware
clocks located within a metre of each other or less, can be several
msec, even when you get the precision below the few msec you observe.
As fudge factors for a couple clocks, I have
fudge 127.127.8.1 time1 0.2201342 time2 0.03034893 flag1 1 flag2 1
# fudge 127.127.8.0 time1 0.2141342 time2 0.02534893 flag1 1 flag2 1
where the time2 value (30msec vs 25msec) is the one to observe.
In comparison with this variance, your distance-from-transmitter
offset is almost insignificant -- though if you have a properly-
calibrated clock and move it cross-country, then you can fudge it
based on the distance with respect to the previous fudge.
> The nature of the polling (serial port at 110 baud) means
> that there's a sawtooth of about 9ms peak-to-peak amplitude. I'm very close
That's as long as you only listen to the serial port data line.
If your hardware and OS support it, you can easily lose this by
tuning GENERIC with a PPS signal from the same clock, which is
enabled by the mode line
server 127.127.8.1 mode 144 minpoll 4 maxpoll 8 burst iburst
as given in the instructions, adding 128 to what you'd use normally.
(And jumpering the data line to DCD.)
In this case, the time1 fudge figure is only used for the initial
offset values, as shortly after starting, the clock then uses the
PPS signal whose offset is the time2 value.
That makes it somewhat difficult to tweak time1, without disabling
PPS, and that's why I don't have accurate time1 values for my
reference clocks -- time2 is the only thing I can tweak with
results. No big loss -- tuning time1 with the sawtooth pattern
of offsets is a pain, as one watches the offsets drift and jump.
> but they may be significant at greater distances. So trying to tweak
> microsecond accuracy out of DCF77 is an academic exercise but of questionable
> practical value.
With this PPS tuning, you'll then see sub-millisecond accuracy.
At least an order of magnitude more stability than you observe
In addition, you can then enable real atom PPS as another refclock,
which adds more filtering and further improves the variance you
would see than by just GENERIC-with-pps alone, to say nothing of
GENERIC-from-serial-data-line only which you have today.
More information about the questions