Last month Brett Oliver contacted me. He already constructed some really cool DCF77 synced clocks. Since Brett is located in Great Britain he faces some challenges though.

The biggest challenge is that his current setup gets slightly out of sync every once in a while. This is of course due to noise / issues with the DCF77 sync. Since my dcf77 library is specifically designed to address this issue he is planning to deploy my library. Current test results are very promising. According to him his PC monitor creates loads of noise but my library still keeps perfect sync. As it seems it meets its design goals 🙂

The second challenge is that he is in a different timezone. When I developed the library it did not occur to me that anyone would want to use it outside the CET zone. But since its decoding capabilities are so good I think this is very reasonable. However at this time I do not want to put timezone handling into the library. So I added a timezone conversion example to the simple clock.

Finally he is also concerned about maintenance outages of DCF77. Although I am not very concerned about them I think he has valid point. The issue is that Arduino (even with a crystal) makes a lousy timekeeper. The typical drift of an Arduino (with crystal) is in the order of magnitude of 30 ppm or more than 1 second per day.

There are several ways to fix this. The most obvious one is to add an RTC. Something that I already planned before. However after digging into ntpd I ponder about a software solution. The idea will be to use the DCF77 signal to infer the drift of the crystal and then compensate for it. This should bring the drift down to 1-2 ppm or less than 0.2 seconds per day. This in turn would get rid of a dedicated RTC and make the whole circuit much simpler.