Page 3 of 3

Re: Real-Time Clock (RTC) drift

Posted: Sun Oct 12, 2014 7:49 pm
by LarryTru
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.

Larry

Re: Real-Time Clock (RTC) drift

Posted: Thu Oct 16, 2014 6:22 pm
by blmorris
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.)
-Bryan

Re: Real-Time Clock (RTC) drift

Posted: Fri Oct 17, 2014 5:31 am
by LarryTru
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.

Re: Real-Time Clock (RTC) drift

Posted: Sun May 03, 2015 7:19 pm
by Jonas
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?

Re: Real-Time Clock (RTC) drift

Posted: Sun May 03, 2015 11:16 pm
by manitou
there was more discussion on http://forum.micropython.org/viewtopic.php?t=598
including adjusting the frequency using calibration registers ...

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

Re: Real-Time Clock (RTC) drift

Posted: Fri May 08, 2015 4:13 pm
by blmorris
I have put up a PR for a new function to calibrate the RTC: https://github.com/micropython/micropython/pull/1239

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

-Bryan

Re: Real-Time Clock (RTC) drift

Posted: Fri Dec 07, 2018 6:13 pm
by volkerforster
[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]http://www.mas-oy.com[/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]http://www.eversetclocks.com/receivers[/url] and the ES100 and ES200 chips do not appear to be broadly available yet. Still looking, will keep posting as I learn more.
[/quote]

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 universal-solder.ca. 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.

Re: Real-Time Clock (RTC) drift

Posted: Sat Dec 22, 2018 12:04 pm
by Hanilein
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: http://docs.micropython.org/en/v1.9.3/p ... 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.