Accurate timing with RTC and timers

[johnlinford]

My first post on this forum, thank you for having me here! I've been using Teenys in my projects for several years with great results and they are my go-to SBC for nearly all my designs.

I have a current Teensy 4.1 project that requires accurate time of day (within, say 100ms) and computation of elapsed time between periodic event interrupts to 1ms accuracy. My approach is to discipline the RTC by NTP updates (every 10 minutes) and use one of the Teensy timers running at 1000Hz to provide 1ms intra-second interpolation.

This works very well except if, as can happen, the network goes down and hence no NTP updates. Testing reveals that without NTP updates the RTC drifts about -400ms per day, which is too much for my application. I would prefer not to have to add a DS3231 RTC if I can avoid it, so I'm looking at other ways to maintain accurate real time over, say, a few days.

The built-in timers seem to be pretty accurate over short time scales. I could use my NTP to discipline the 1000Hz timer to maintain real time rather than the RTC but I don't know whether the timer would be any better than the built in RTC over a period of hours or days.

Before I hack into the code perhaps someone can answer these questions:

• What is the clock source for the built-in timers?
• Is its long term accuracy likely to be any better than the RTC?

Grateful for any insight.

John

 

[MarkT]

That's about 5ppm out, not bad for standard quartz crystals (which are usually rated +/- 20, 30 or 50ppm). What accuracy do you need?

 

[johnlinford]

Yes, I realise that it's not bad for a non-temperature compensated crystal oscillator - I think the spec is something like 20ppm. Ideally I'd like to get to around 1ppm. I can easily compute the RTC drift over time, so perhaps another possibility is to apply software corrections to the oscillator divider chain if it's accessible.

 

[sicco]

A gnss module maybe? The 1 pulse per second output on legacy gps modules used to be pretty accurate already, and a UTC timestamp is given for free. Works indoors also nowadays with Galileo.

 

[johnlinford]

I did think about GNSS and have used it in other designs, it would be more than adequate. In the end it may be the only realistic way to get the sort of accuracy I am after. I was just hoping I could avoid the additional complexity and the risk of unreliable satellite coverage - in my experience indoor coverage is certainly not a given. The more I think about it the more I am concluding that GNSS might be the only realistic option, perhaps with an external antenna.

 

[el_supremo]

Another possibility might be to use the time signal from radio stations - WWVB in North America, MSF in the UK, DCF77 in Europe, etc.

Pete

 

[johnlinford]

I had forgotten about MSF et al! Yes that would work, especially as the 60kHz MSF transmitter is just down the road from me. Years ago I designed a clock based on MSF and it worked well, though the data rate is so low that it takes a full minute to sync. ISTR that I stopped thinking of MSF as a reliable time source when it was off for over a week for some extended maintenance... perhaps I should look again.

 

[thebigg]

I know you said you didn't want to add a DS3231, but have you considered one of these?

RV-3028-C7

RV-3028-C7 RTC module is an Xtreme low power (45 nA), highly accurate (±3 ppm ) I2C Real-Time Clock with battery switchover and trickle charger. UNIX time format.

www.microcrystal.com

Accuracy is great for my purposes and it needs so little power that a supercapacitor will keep it alive and accurate for more than a month.

 

[johnlinford]

I wasn't aware of the RV-3028-C7 but it looks like an interesting device and I can certainly think of applications where it would be useful. Thanks!

Thanks everyone for all the external RTC source suggestions but TBH I was rather hoping to learn more about the Teensy 4.x RTC and timers. For example, the RTC 32kHz clock divider chain may be programmable or the timers might have a closer tolerance clock source. I guess neither is particularly likely but it's always worth asking!