Real-Time Clock (RTC) drift

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
Posts: 26
Joined: Wed Aug 06, 2014 5:46 am

Re: Real-Time Clock (RTC) drift

Post by LarryTru » Sun Oct 12, 2014 7:49 pm

Yes, it might still be OK. When I did a manual spot check a couple of weeks ago I was surprised how much it drifted, but more careful measurements will allow us to know just how much it really is. In my spare cycles I'm working on an automated measurement method. If that doesn't work out easily, I'll just do it manually.

On a related note, I realized today that the date/time tuples used by functions in the Time and RTC modules are different. The values are ordered differently, the RTC module includes "subseconds" while the time module instead includes "yearday", and the weekday starts with 0 for time module and 1 for the RTC module. These differences "might" have contributed to the drift I thought I saw. I might have misinterpreted the time I thought the functions were returning.


Posts: 345
Joined: Fri May 02, 2014 3:43 pm
Location: Massachusetts, USA

Re: Real-Time Clock (RTC) drift

Post by blmorris » Thu Oct 16, 2014 6:22 pm

Quick update - I have set up an experiment in which I have the pulse-per-second output of a GPS module connected to my pyboard to trigger a callback to print the RTC sub-second counter along with pyb.millis() % 1000 (just the fractional milliseconds part of the counter) once each second. I set it up last night and again today, and my results suggest that the primary oscillator on my pyboard (the 8 Mhz one) is roughly 33 +/- 1 ppm fast, while the RTC crystal is about 135 +/- 3 ppm fast. The measurement of the primary frequency seems reasonable, but the RTC crystal seems way off. I don't have any calibration applied to the RTC crystal; while I think that I have succeeded in setting the calibration registers, I haven't figured out how to make a calibration take effect just yet; the calibration values also don't persist through a soft reset, so I still need to check what I am doing (and take a closer look at the uPy RTC initialization code.)

Posts: 26
Joined: Wed Aug 06, 2014 5:46 am

Re: Real-Time Clock (RTC) drift

Post by LarryTru » Fri Oct 17, 2014 5:31 am

That's very interesting and supports the "feeling" that the RTC is not as accurate as it ought to be. I've made very little progress on my measurement mechanism; day job taking precedence.

Posts: 29
Joined: Fri Jan 23, 2015 8:32 pm

Re: Real-Time Clock (RTC) drift

Post by Jonas » Sun May 03, 2015 7:19 pm

Did anyone find a solution to the rtc drift?
Mine runs about ten seconds ahead after 24 hours...

Thinking of changing the crystal to a +-10ppm, or find out more exact how much the drift is and then make it reset the seconds to zero when that number of seconds after midnight have past...

What do you think?

Posts: 67
Joined: Wed Feb 25, 2015 12:15 am

Re: Real-Time Clock (RTC) drift

Post by manitou » Sun May 03, 2015 11:16 pm

there was more discussion on
including adjusting the frequency using calibration registers ...

your "10 seconds per 24 hours" is 115ppm, about what others have been measuring.

Posts: 345
Joined: Fri May 02, 2014 3:43 pm
Location: Massachusetts, USA

Re: Real-Time Clock (RTC) drift

Post by blmorris » Fri May 08, 2015 4:13 pm

I have put up a PR for a new function to calibrate the RTC:

Wanted to mention it here in case there is anyone interested in the RTC but not following on GitHub.


Posts: 1
Joined: Fri Dec 07, 2018 5:50 pm

Re: Real-Time Clock (RTC) drift

Post by volkerforster » Fri Dec 07, 2018 6:13 pm

[quote=blmorris post_id=1719 time=1412993604 user_id=174]
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 [url][/url] 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 [url][/url] and the ES100 and ES200 chips do not appear to be broadly available yet. Still looking, will keep posting as I learn more.

I came across this older posting, and I want to add something to it:
- We produce and sell 60kHz tuned AM receiver kits for WWVB, MSF or JJY-60, and a 77.5kHz kit for DCF-77, based on the mentioned MAS receiver chip.

- We also carry EverSet ES100 development kits for WWVB BPSK, and sell them exclusively in out online store Documentation and an Arduino test sketch is also available for download on our website.

- The mentioned ES200 will most likely not be manufactured.

ES100 kits are currently out of stock, after an initial batch was sold out within 2 days, but more will be available within the next days, after the modules have been tested.

Posts: 20
Joined: Thu Jul 12, 2018 11:40 am
Location: Christchurch, New Zealand

Re: Real-Time Clock (RTC) drift

Post by Hanilein » Sat Dec 22, 2018 12:04 pm

I am working on a code to self-adjust the RTC on the PyBoard. It is a learning exercise, and i am not finished yet.
The idea is, to use a GPS with a PPS (I use the Adafruit ultimate GPS) and compare the RTC output to the PPS signal.

The rtc.datetime() function supplies a subsecond value, which is 1/256 of a second.
The rtc.calibration(correctionvalue) accepts a correction value for the rtc.

documentation: ... b.RTC.html

The algorithm basically is called from an ISR, which is triggered by the GPS PPS signal.
It calculates the correctionvalue by checking, if the subsecond number from the current second has changed since the last second.

It works reasonably well, and the next steps are to consider the temperature drift of the crystal and produce a look-up table to eventually get rid of the GPS.

Currently i am moving that code in a class, it is messy, which is why i am not posting it here straight away.

I'll keep you posted.
Good decisions are based on experience. Experience is based on bad decisions.

Post Reply