[ntp:questions] Change reference clock soon after DCF-signal islost

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Wed Jul 21 07:02:40 UTC 2010

Rob <nomail at example.com> writes:

> Matuschka, Sebastian <Sebastian.Matuschka at gcd-solutions.de> wrote:
>> The reason i want to switch very soon to another source when DCF77
>> signal is lost, is that I have to tell a FPGA when it should use the
>> DCF77 signal and when to use an alternative source. The FPGA doesn't
>> decodes the time but it uses the DCF77 signal to increment its internal
>> RTC.
>> The MCU on which the ntpd runs has to decide whether the FPGA should use
>> the DCF77 or a "once per second pulse" from the MCU.
> I think this isn't a good design.
> In my experience, DCF-77 reception is simply not stable enough to directly
> use the pulses from the receiver as clock ticks.
> When there are thunderstorms, local interference, and sometimes propagation
> problems, there can be spurious extra pulses that you do not want to
> count.  Or pulses can be missing.

The PPS filter should be able to deal with that (plus indicating the
problems). Also when decoding the DCF-77 pseudo-noise, you may lock
quite closely to the signal. Don't expect a 5 Euro receiver to lock on
pseudo-noise-however. Also by nature, DCF-77 will provide 59 pulses per
minute, not 60. So you should slave a clock that, in turn, created the pulses.

> A good way of using DCF-77 is to collect the 59 pulses that make up a
> minute, average the offset between the pulse start and the local clock tick,
> decode the time from the pulse lengths, and then at the end of the minute
> decide if all this information is valid and should control the clock
> (adjusting the clock offset/frequency), or should be discarded as a whole.
> This is also what the DCF-77 drivers in ntpd do.



More information about the questions mailing list