Happy new year 2015. Hope everybody started it well. I looked it up, I am now working about 2 years on my DCF77 library.

It all started with the binary clock as a benchmark at the first of December 2012. Then I went on to improve upon it till it all culminated in my DCF77 library. Now am I satisfied with it? Yes and no. Yes: this is probably the best Atmega 328 based DCF77 library ever. Its noise tolerance beats all other libraries I am aware of. No, this is not even close to what would be possible on a mightier platform. With an ARM core I could have significantly more memory, more CPU power and a better interrupt system. This is turn would allow the following features:

1. Use 1000 bins (or even 2000) for the phase lock instead of just 100. Thus the phase could be nailed down to 1 ms instead of 10 ms. This would reduce phase jitter which is relevant if used as a NTP stratum 0 clock. It would also recuce the time for auto tuning by a factor of 10.
2. Keep a local history of the signal (e.g. the last . Thus the recursive decoder stages could use data that is otherwise lost until the previous stages lock. Or to put it that way: reduce cold start sync lock time roughly by a factor of 5. This is especially important under noisy conditions.
3. Have large bins sizes and less decoder stages. Again this would decrease time to lock.
4. Replace the decoded bits by the sum of the sampled bits during sampling of the bins. This basically allows to differentiate between 0, 1 and unclear signals in between. According to theory and all I read from the literature this should give me some more dB of noise tolerance.

However for the time being I am somewhat undecided if I will push this much further. The reason is that the library is more than good enough. If it fails to lock the main reason is that the typical DCF77 receiver fails to demodulate anything reasonable at all. Also I found that its noise tolerance even under very adverse conditions was more than enough. On the other hand I might use it as a test case for Arduino Due experiments – who knows 😉

At this time I will now focus on some applications for it. The first application will be a time switch. My design goals are as follows.

1. Have a lot of independent outputs. Arduino exposes 20 pins and I need 2 for the serial port and two for DCF77 in plus monitoring. In addition 16 bits fit nicely into two bytes. Thus the time switch will have 16 channels.
2. Have a lot of triggers. Since everything has to fit into 1k of EEPROM I will go for 100 triggers.
3. Have the capability for repetetive triggers, e.g. daily, hourly. With other words allow for some kind of “joker”.
4. Behave like a mechanical time switch.
5. Have some interface that can be accessed through the serial connection which is suitable for humans AND computers

Not a design goal: driving an LCD display.

The “behave like a mechanical time switch” requires some explanation. Let’s have a look at a typical mechanical time switch.

Due to its construction it does not trigger at a point in time. Instead it triggers for the whole period. Typical digital time switches behave differently. They trigger at the start/end of a period and keep their state in between. Not a big difference, except if the clock starts up in the middle of a period. So what I wanted is a clock that will look back to find the start of the current period and trigger accordingly.

Sounds simple. Well, I thought the same. However this is more of a challenge than I would have thought of. The issue is the combination of the joker mechanism with the “behave like a mechanical time switch”. You may wonder why this should be so hard. The issue is to figure out the latest trigger that would have fired. This implies to be able to compare the triggers relative to the current time. As it turns out this is really devious and hard to debug. Still I am absolutely sure that I can resolve this. So stay tuned 🙂