Real-Time Clock (RTC) drift

[LarryTru]

Sorry, I did mix the ideas a bit.

Agreed, using a 50/60 hz reference signal is preferable since it ensures the clock runs accurately all the time.

In case a method to generate a reference signal is not found, I was also weighing the alternative for correcting drift by periodically resetting the time with a GPS reference.

I thought about wwvb, but assumed it would be harder than that link you provided makes it look. Very interesting.

Larry

[pythoncoder]

While the AC line frequency is controlled, it varies in the short term as variations in the power demand on the grid cause alternators fractionally to slow down or speed up. The managers of the grid constantly correct this by adjusting the power pumped into the grid so that, over periods of hours, it's very precise indeed. But to use it to synchronise a clock crystal would be difficult in my view because its instantaneous value lacks sufficient precision.

The radio signals I mentioned are specifically intended as standards and are derived from atomic clocks.

Regards, Pete

[LarryTru]

Hello,

Yes, I was reading about variability in AC line frequency today. Previously, I thought it was rock solid. As you said, turns out not so much. Still, even with variations, my guess is it would result in much improved accuracy. Still not that great for me since I'm planning battery powered projects.

RF time references could guarantee near perfect accuracy, but might not be as available as AC current in some environments.

The other difference between methodologies is how the clock is calibrated. With a 50/60 hz line voltage reference we get to use the hardware's calibration mechanism. With the RF method, we have to periodically reset the clock via software. right? I've only looked at WWVB so far, but you can't easily get a 60 hz reference signal from that.

Larry

[blmorris]

The other difference between methodologies is how the clock is calibrated. With a 50/60 hz line voltage reference we get to use the hardware's calibration mechanism. With the RF method, we have to periodically reset the clock via software. right?

Not necessarily. The hardware calibration mechanism stores values in the CALM and CALP (minus and plus calibration) registers. These registers could also be set directly, and the values stored there will persist as long as there is power available to the VBAT domain (i.e. as long as a backup battery is connected). It should be possible to derive the calibration values to compensate for a given crystal by monitoring the drift of the sub-second register against any available reference signal. I'm trying to work out just how to do this; I am using the stm and uctypes modules to access the special function registers from within micro python. (I think that I am getting there, but I have a few questions about using uctypes that will be the topic of another post.)

Shifting the topic slightly, I have also been researching chips to demodulate the signal from the various LF time standard radio signals, and getting a bit frustrated. It seems that some of the chips that have been commonly used are no longer being broadly distributed in the US. Specifically, Digikey no longer carries the C-Max CME6005 or CME8000 chips or any modules based on them, and Sparkfun has also discontinued the modules. There is also the MAS6180B from Micro Analog Systems http://www.mas-oy.com which I haven't found anywhere.

I suspect that this may have something to do with the recent technology upgrade to the WWVB signal to add phase modulation to the old amplitude modulation to provide for better reception at low signal levels. As far as I can tell, the only company advertising chips to utilize the new technology is XtendWave, with their Everset line http://www.eversetclocks.com/receivers and the ES100 and ES200 chips do not appear to be broadly available yet. Still looking, will keep posting as I learn more.

-Bryan

[LarryTru]

Interesting methodology to use the internal calibration values.

I also found that the previously popular chips and breakouts are no longer available.

I did't find the Micro Analog Systems one.

You're way ahead of me.

Larry

[LarryTru]

Is there a parts list for the pybpard? I couldn't find one. I want to check out the specs for Y2, the RTC crystal.

Larry

[dhylands]

All of the information for the pyboard is in this repository: https://github.com/micropython/pyboard

This file contains a BOM:
https://github.com/micropython/pyboard/ ... sembly.pdf

The 32kHz crystal is listed as having a part number: 9HT10-32.768KBZF-T
This appears to be the datasheet: http://www.txccrystal.com/images/pdf/9ht10.pdf

[LarryTru]

Thanks for that tip. I should remember that everything important about the project is on github.

With that crystal, it seems to me the clock should be more accurate than I have observed. I need to do some measurements, but I'm wondering if there is some other cause for the drift. Previously, I assumed the crystal was why it drifted so much.

Larry

[LarryTru]

The crystal used on the pyboard is not as accurate as the data sheet linked below states. That data sheet is for the +/-20PPM crystal TXC sells. But the one specified for the pyboard is +/-50PPM

The "B" in the part number corresponds to +/-50PPM as shown here: http://www.txccrystal.com/images/pdf/nu ... al-khz.pdf

[blmorris]

That could explain the high drift you are seeing. I'm interested to find out what you actually measure.
This is still well within the calibration range of the RTC driver, so you might still be able to get away with it for your project. The only question is whether the change in this crystal's frequency due to temperature or aging throws you off too much.
I'm inching closer to getting a calibration routine, but I won't be able to test anything in the next few days. I will post whatever code I can get to work.
-Bryan