Rob <[email protected]> writes: > Matuschka, Sebastian <[email protected]> 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. Yes. Regards, Ulrich _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
