[ntp:questions] Re: Compensating DCF77 radio signal propagation delay

Jan Ceuleers janspam.ceuleers at computer.org
Sun Nov 16 20:38:26 UTC 2003

On Sun, 16 Nov 2003 18:23:44 +0100, Xisco Lladó <timekeeper at bitic.net>

>This propagation delay varies during day and seasons but I think it 
>could be compensated with a mean value of it.
>Do you know any method to calculate it? I would like to fix it with 
>fudge parameter.

You can either try and calculate the delay, or you can measure it.

The calculation involves identifying all of the factors that
contribute to the delay and calculate / estimate each of them. As you
say, one delay factor is the propagation delay, which can be
calculated with the propdelay program that is included in the ntp
distribution (check the clockstuff directory), but that is not the
only delay factor.

Each parse refclock has a default delay already compiled in. The
default value is overridden by the fudge time1 factor. In your case
(mode 14), this compiled-in default delay is 258ms. You will note that
this is very much larger a delay than the propagation delay that
propdelay comes up with. The most significant component of this
systemic delay is the amount of time it takes for a byte to be
transmitted across a serial port at 50 bit/s, with the remainder
presumably being budgeted for overheads in the UART and OS.

I asked the author of the parse refclock (Frank Kardel) about the
rationale behind the 258ms value recently, and here is his answer:

=== quote
Yes most of it comes from the data transmission.
The pulses are 100 and 200ms +- receiver timing. The 258 ms value
was measured around 1993 by someone for the commercial IGEL:clock.
A pretty expensive item for being a simple receiber. That thing had
a baud rate converter to 1200 BAUD thus i suspect the delay to be
related to that. It is a true emperical value. The simple recceivers
vary VERY much with their delays.

We build our own receiver at that time and it had a delay of 210 ms
@50Baud. That is pretty much the expected delay 200ms for 10 bits and
10ms for sampling at the bits mid-point. That was the closest match to
theory. All other variants had more or less bigger delays. See the
constants in the RAW DCF variants section in ntpd/refclock_parse.c.
=== end quote

So: you would need to estimate the systemic delay for your particular
combination of refclock, UART settings (low_latency), OS and interrupt
latency. This is rather difficult.

The alternative is to measure the delay instead. You can do this using
the "enable calibrate" method described at
http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#cal . In my
case this yielded a fudge time1 value of around 241ms (I'm in Brussels
and am using a mode 16 DCF refclock), which you will note is below the
258ms default value, and which covers all sources of delay (including
propagation delay and the various other kinds of systemic delay).

Best of luck,


More information about the questions mailing list