TUNE your Ice Tube CRYSTAL: HARDWARE or J. Archie software

[jarchie]

...you asked this a few days back " After both clocks woke from sleep, did you notice if the rev d board ran fast for the first five to ten minutes?" I used the term clock race to describe this...

Thank you. I didn't understand what you meant by the phrase "clock race," but I get it now.

Bug is a coined word to describe a situation or problem that arises undesirably at certain times, while not being present at other times.

I use the word "bug" a bit differently, so I looked it up. Merriam-Webster defines "bug" a bit more generally--"an unexpected defect, fault, flaw, or imperfection <the software was full of bugs>"--and that is what I meant when I used the word "bug." I apologize for the confusion.

My point here is I don't know if I am conveying my thought on software correction being defined during battery/sleep.

I understand your claim--or at least I think I do. My point is that there are other possible explanations for the drift you observed.

In fact, it's easy to show that drift correction functions during sleep. I defined AUTODRIFT_CONSTANT to 1 in config.h and programmed a clock. With that definition, the clock should advance by an extra 1/128 second for every clock-second. So I set the time and waited 128 seconds... as expected, the clock was one second fast. I again set the time, immediately unplugged the power adapter, waited 128 seconds, and plugged the adapter back in... the clock was still one second fast. Therefore the software drift correction does seem to work while awake and while sleeping.

From my calculations and test, 2 seconds a week would amount to a .1 hertz deviation, exactly what I found.

Apologies here... my mistake! The difference was 2 seconds over one week--not a week and a half--so the difference is on the order of 3 ppm or 0.1 Hz. But my point remains the same. Software drift correction should function normally during sleep, so the timekeeping discrepancy you observed almost certainly has another cause.

[russell 27]

OKAY. Believe I found an answer here. It's not that the software correction does not define itself during battery backup, board mounted crystal deviates slightly more with lower battery Vcc. My particular Archie clock with 10 Pf load capacitors was tuned to 32767.9 hertz, a -.1 hertz deviation; at battery 2.9 Vcc an additional -.1 hertz crystal deviation occurred. While the initial -.1 hertz deviation was corrected by the software during battery backup, the additional -.1 hertz was not, causing the 2 second loss. One of my external crystal oscillator circuits I tested held tune down to 2.6 Vcc. I stated earlier that this method is superior to software correction for battery backup accuracy, that is true, it has the potential to do so. One solution; using a higher battery backup Vcc would alleviate this, also; extra software deviation correction could be defined during battery backup. Depending on how much initial deviation is present, You may or may not notice any time deviation during a several hour power loss.

[jarchie]

One of my external crystal oscillator circuits I tested held tune down to 2.6 Vcc. I stated earlier that this method is superior to software correction for battery backup accuracy, that is true, it has the potential to do so.

I'm convinced that your external crystal oscillator performs better during sleep. I wish I could offer more points of debate, but I'm afraid you'll need to find a better skeptic than myself. :-)

[jarchie]

My particular Archie clock with 10 Pf load capacitors was tuned to 32767.9 hertz, a -.1 hertz deviation; at battery 2.9 Vcc an additional -.1 hertz crystal deviation occurred. While the initial -.1 hertz deviation was corrected by the software during battery backup, the additional -.1 hertz was not, causing the 2 second loss.

This kind of voltage dependence isn't unusual for oscillator circuits, and the datasheet for the DS32kHz TCXO gives a typical deviation of 2.5 ppm (0.08 Hz) per volt.

But I'm curious if you guys think the frequency deviation during sleep is going to be similar among clocks. If so, it would not be difficult to add a software sleep correction. Of course, a software solution would not be as elegant as Russell's hardware oscillator, but it might achieve comparable accuracy.

The xmas firmware measures the system voltage after the clock has been sleeping for about 10 minutes. The delay allows system voltage to fall to the battery level. Presently, that measurement is only used to display a low battery warning upon waking ("bad batt"), but the approximate system voltage during sleep might be useful information for calculating the necessary sleep correction.