Last month I implmeneted the first extension to my library to help Brett Oliver with his new clock.
I struggled quite a bit with the decision if crystal frequency compensation will go into my library or not. After all the goal of this library is maximum noise resilence. Finally I came to the conclusion that a signal outage is some kind of noise. Thus handling it as good as possible is congruent to my goals for this library. Consequently I implemented this.
The next step is to add some autotune feature for the frequency adjustment. Although this is not to hard to implement it takes long to test it. This is not because it is hard – it is because the involved time constants are in the range of days. Thus I just can not test the autotune feature overnight.
Stay tuned for the next release of the library as it will support autotune to 1 Hz or 1/16 ppm.
Blinkenlight 
Hallo Udo,
Es gibt ein kleines Problem mit dem Link ” crystal drift compensation”. Er führt zu einem
“not found” error.
Grüße
Werner
Vielen Dank für den Hinweis. Sollte jetzt funktionieren.
Udo
One note about your termminologie. The drift compensation as you call it and as you implemented it is actually not an drift compensation but a correction of the difference between the actual frequency and the nominal frequency. The main cause of drift is temperature and therefore cannot be compensated by a single constant value. In professional frequency counters they use temperature (oven) controlled quarz oscillators (OCXO).to compensate for the drift caused by change in temperature. Another way of compensating for the drift would be to compare the carrier requency of DCF77 which is like the seconds controlled by a caesium clock with the current quarz frequency.
Werner
You are definitely right. I will fix this accordingly. May take some days though.
OK, I put some thoughts into it. I agree that the main source of frequency drift is temperature. However my terminology was not that bad. I never said frequency drift. What I had in mind was phase drift. Of course the first order cause for phase drift is a frequency offset. However you are right, that most experts might think in the frequency domain and thus assume frequency drift. So now what to do about it? I think the best solution is to rename “drift” into “cumulated_phase_deviation”. If someone has a better name I would happily adopt it.
With regard to the OCXO I like to disagree though and the DCF77 carrier I tend to disagree though. An OCXO can not compensate drift. It just keeps temperature stable and thus eliminates the major source of drift. Still aging and vibration are present.
With regard to the carrier of DCF77 you are right. I could phase lock to the DCF77 carrier and would be fine. However this does not fit into my project for the following reasons: (1) it requires to much additional hardware. (2) it does not work during carrier loss. Also the minimal Allan Deviation for a crystal is usually in the range of tens of minutes to some hours. Thus frequency drift compensation does not require the DCF77 carrier. Frequency locking to the demodulated signal is reasonable (although inferior if you want maximum precision).
Conclusion: continous auto tuning will provide drift compensation but I agree – it should be called frequency adjustment or frequency control.
Thanks a lot for pointing this issue out 🙂 I welcome any feedback, especially if it is knowledgable.