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.
LarryTru
Posts: 26
Joined: Wed Aug 06, 2014 5:46 am

Real-Time Clock (RTC) drift

Post by LarryTru » Sun Oct 05, 2014 10:44 pm

Hello,

I didn't see anything posted anywhere about others noticing significant drift in the RTC.

I have noticed that mine drifts quite a bit. Has anyone else already noticed this and looked into it?

I saw that the data sheet says that the RTC can be calibrated. But I haven't tried to learn about that yet. First I was wondering if anyone else has already looked into it and understands it.

Thanks,

Larry

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

Re: Real-Time Clock (RTC) drift

Post by blmorris » Mon Oct 06, 2014 8:08 pm

Hi Larry-
In order to achieve reasonably high accuracy from an inexpensive 32.768kHz crystal it will usually be necessary to calibrate. I have observed the same RTC drift on a board I designed with the same processor as the pyboard.
The full documentation for the RTC is in chapter 22 of RM0090, the programmer's reference manual for STM32F4xx processors. (warning - large download)
Micropython doesn't support the RTC calibration features yet, at least not directly. However, the stm module does provide references to all of the RTC registers. (Disclaimer - I haven't yet attempted to do anything interesting by directly manipulating registers from the stm module.) The stumbling block for my own calibration efforts was that I didn't have a sufficiently precise reference signal for calibration.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Real-Time Clock (RTC) drift

Post by dhylands » Mon Oct 06, 2014 8:49 pm

How accurate would a GPS which generates a pulse-per-second output be? Perhaps if averaged over an hour or something?

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

Re: Real-Time Clock (RTC) drift

Post by blmorris » Tue Oct 07, 2014 2:33 am

dhylands wrote:How accurate would a GPS which generates a pulse-per-second output be? Perhaps if averaged over an hour or something?
With a good satellite fix, the PPS output of a GPS is phenomenally accurate. I was thinking along the same lines last year, and acquired this GPS module from Adafruit. If I recall correctly the expected pulse to pulse jitter is less than 10 nanoseconds (corresponding to roughly 10 feet positional accuracy, and 0.01 parts-per-million accuracy.) Averaged over time the relative accuracy only gets better, approaching atomic clock levels - because, of course, you are getting a clock synchronization signal from a group of GPS satellites, each one of which is carrying its own atomic clock. (I believe they use cesium standards, but I should look that up again.)
Since that just wasn't good enough for me ;) I went as far as getting an Oven Compensated, Voltage Controlled Crystal Oscillator (OCVCXO) with the idea that I could use the PPS output of the GPS as a reference, counting oscillations per pulse with a micro controller and using that to generate a compensation voltage to pull the oscillator into perfect long-term lock with the GPS signal (essentially a weird hack of a PLL), thereby getting an atomic-locked frequency standard without the jitter, and the ability to divide down to get lower frequency reference signals as well.
Sadly, the sticking point was that I work in a reinforced concrete building and got essentially no GPS signal at my desk or work bench, and I moved on because there was other stuff to do. However, my boss has been making noises that he might be interested in the project again, so I may pick it back up, this time perhaps with a micropython assist.

Of course it doesn't need to be that complicated just to calibrate the RTC, and we have other reasons for wanting to build a high-precision time standard. I was also hoping to utilize the built-in synchronization features of the STM32F405's RTC module, which requires an input of 50 or 60 Hz, (or it might have been 512Hz, need to look it up.) But a clever program could certainly calibrate the RTC directly from the GPS PPS output, given enough time to do the comparison. And in the end, any more precision is overkill for calibrating an inexpensive low-power watch crystal like the one in the pyboard (and in my own project). These crystals usually are rated to +/- 20-30 ppm accuracy (even before taking temperature variation into account), and +/- 30 ppm is +/-2.6 seconds per day - easily noticed when we are accustomed to PC clocks synchronized by NTP. The RTC module on the pyboard can calibrate with ~1 ppm resolution, or 0.09 sec/day (using a 20-bit counter which rolls over every 32 seconds and adding or subtracting a small number of ticks per cycle). This is obviously much better than not calibrating at all, but it still won't eliminate drift due to aging or temperature.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Real-Time Clock (RTC) drift

Post by pythoncoder » Tue Oct 07, 2014 4:36 pm

One way to calibrate clocks here in the UK is the Anthorn time signal. This uses a very low carrier frequency which should be able to penetrate most buildings. Another is the 200KHz radio 4 long wave (assuming it still exists) carrier, which is very precise. But you probably knew that ;)

Regards, Pete
Peter Hinch
Index to my micropython libraries.

nekomatic
Posts: 37
Joined: Thu May 08, 2014 9:31 pm

Re: Real-Time Clock (RTC) drift

Post by nekomatic » Tue Oct 07, 2014 6:31 pm

Radio 4 long wave still exists last time I checked, but it's been 198 kHz for many years now...

fma
Posts: 164
Joined: Wed Jan 01, 2014 5:38 pm
Location: France

Re: Real-Time Clock (RTC) drift

Post by fma » Wed Oct 08, 2014 4:55 am

In europe, some people can receive the DC77 signal, from germany. But I don't know if the bit rate (1bit/s) is accurate enough to calibrate a RTC...
Frédéric

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

Re: Real-Time Clock (RTC) drift

Post by blmorris » Wed Oct 08, 2014 3:31 pm

There are actually two issues in play here. One is the problem of accurately setting the RTC to the current time. Given that most people will be able to connect their pyboards to an internet-connected computer, and most computers these days will automatically synchronize with a good time reference using NTP, it should be straightforward to write a python script to synchronize the pyboard's RTC with the clock on the host computer. (I haven't done this yet, I hope to tackle it as a learning exercise.)

The other problem is compensating for any inaccuracy in the watch crystal frequency. I use a crystal with a rated frequency tolerance of +/- 20ppm; I haven't looked up the watch crystal used on the pyboard, but I expect it would be similar. At the limits of this tolerance there will be a drift of well over one second per day.
The pyboard processor provides a hardware mechanism to compensate for variations in crystal frequency. The way it works is that the RTC has a free-running sub-second counter running at the crystal frequency, nominally 32,768 Hz (2^15). The counter is 20 bits wide, so if the crystal oscillates at exactly the nominal frequency, 2^20 sub-second ticks will be exactly 32 seconds. The RTC hardware can accept a high-precision reference signal of either 50 or 60 Hz on pin PB15 (pin 36) and determine how many sub-second ticks to add or subtract during each 32 second period to synchronize the RTC counter with the reference clock. SInce 1/2^20 = 0.9537e-6 (just under 1 ppm), each tick added or subtracted corresponds to roughly 1 ppm adjustment. In theory, RTC calibration can provide clock accuracy of +/- 0.477 ppm or 0.04 sec / day of drift.

Therefore, using the automatic calibration subsystem simply requires a reasonably precise logic-level signal at either 50 or 60 Hz. Precision much better than 1ppm doesn't help much.
I finally realized that the reason it was designed this way is that it is relatively simple to derive this signal from grid power; in most developed countries the grid power frequency is tightly tied to standard time; there will be some very small short-term deviations as the grid deals with peaks and dips in demand, but all the power plants feeding the grid must maintain tight frequency control to remain synchronized with each other.

That is one approach. It should also be possible to write a routine that accepts the PPS signal from a GPS that will work just as well (but probably not any better, given the available calibration resolution.) It could even be fun to build a receiver to pick up the 60kHz signal from Anthorn (or WWVB in Boulder, Colorado for North America) and derive a reference signal that way.

To that end, I have started digging into the details of the RTC hardware at the register level using the stm and uctypes modules - this is powerful stuff, and easy to crash your hardware if you don't know what you are doing, which I certainly don't ;) But I have managed to expose and read the sub-second register, which makes me believe that I'll get there eventually.

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

Re: Real-Time Clock (RTC) drift

Post by LarryTru » Wed Oct 08, 2014 11:58 pm

Very Interesting, That was exactly the sort of information I was looking for when I started the thread. Personally, I'm not concerned with the initial setting of the clock, I want it to be more accurate and not drift so much (I know that's not very precise, but I haven't decided how much drift is acceptable; much less than it does now) between settings which could be 6+ months apart.

I saw that 50/60 hz reference signal calibration mechanism. For AC powered projects, deriving it by sampling line voltage would be near perfect. However, I want this for projects where AC power is not available. GPS could fill that gap, except it feels like overkill and would consume significant energy unless disabled most of the time and even then it would drift between settings.

I like the radio receiver idea. But I don't know what the power demands would be; presumably less than GPS.

I wonder if there is an IC somewhere which does nothing but receive and decode the time signal from GPS (no location services). For that matter, I wonder if any of the GPS receiver ICs can be run in a lower power mode where everything is disabled except for time reception.

Lots of questions. I'l try to run some of them down.

It's an interesting problem anyway (at least to me).

Thanks,

Larry

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

Re: Real-Time Clock (RTC) drift

Post by blmorris » Thu Oct 09, 2014 3:24 am

The idea behind calibrating to a reference signal is that you can reduce the RTC drift to an acceptable level and have it stay accurate as long as the RTC stays on backup battery power. However, your idea about a low-power GPS time receiver got me to wonder how hard it would be to decode the WWVB signal - probably not too hard: http://www.joejaworski.com/wwvb/
Maybe use the pyboard instead of the PIC to decode the bits?
Going to keep this message short, but I'm looking into this now- your questions have me taking a fresh look at my old project, so I'm happy to keep the discussion up.

Post Reply