Clock fast on Giga R1

Official Hardware Mega GIGA R1 WiFi
1

Hi,

I have noticed by comparing my onboard RTC (with LSE oscillator selected as source) to an accurate off board RTC that the onboard clock is a little fast. I’ve tried a number of approaches and everything seems to run a little fast.

I got here because my clock (NTP’d with fractional seconds and latency adjustment - not the standard arduino NTP) slowly speeds up relative to a server I’m running timings against. This led me to benchmark it against the off board RTC I have.

I’ve tried a number of approaches to tracking elapsed time so I can have a fractional clock, millis(), micros(), reading the sub second register of the onboard RTC and counting the ticks, using mbed::Ticker with 1ms interval.

I’ve read articles saying clock accuracy on the STM32s is generally poor. I’ve read articles where people say they are getting very accurate microsecond timings.

If I write a test harness that does nothing but checks timings the results are better but running this stuff in an app accessing various devices like USB, touch display, networking etc and the clocks perform worse.

What are people’s experiences in running fractional clocks that stay accurate for longer than 15 minutes?

I’ve considered counting clock cycles but I’m not sure if clock cycles are constant time in all situations on the M7.

2

If I need that much accuracy I use a real RTC the DS3231 (NOT the ZS-04 that is flawed) if a remote install, or NTP if hard wired, but always with a DS3231 as backup)

3

I’m not an embedded developer and spent most of my life working on kit where I can assume microsecond accuracy clocks. Lesson learnt (I’m learning a lot of these due to inexperience). Do you take the square wave output from the DS to synthesise fractional seconds?

4

I guess this is what I should have read before starting

5

I don't need anything that fine as a hobbyist. Back in the day when they paid me we had RTC clocks built on to the processor boards. I forget how fine they were but I doubt is was much better than 1 second back in 2000.

6

Hi @schnoberts. What degree of accuracy are you looking for? The GIGA RTC is capable of 1 ppm, so +/- 1s over ~12 days if calibrated.

7

At this stage I think I need to capture more data and draw some graphs. If my device can do 1ppm, I must be doing something wrong. Clearly my system is doing a lot, it’s streaming data over WiFi, it has the M4 polling I2C and various other things and it’s running a GUI, reading disk etc. Obviously this isn’t a quiet tight loop environment idealised environment, but nevertheless, I think some graphs are in order.

8

I doubt you're doing anything wrong, you just need to calibrate.

Sync with a good source and then measure your drift to calculate a value for the 'smooth' calibration function below. For 'the best' value, drift over 12 days, 3hrs and 16mins should be measured and 1 calibration point per 1 second drift over the period is used. For a quicker return (with lower accuracy) 12 points per sec over 24hrs, 12*24 per 1s over 1hr etc.

If you're running fast, I certainly was on my 3 boards, a negative val will be required. Needs to be set whenever backup domain looses power (RTC batt removed).

extern RTC_HandleTypeDef RTCHandle;

void LSEcalibration(int16_t LSEcalibrationvalue) {
  if (LSEcalibrationvalue > 0) {
    if (HAL_RTCEx_SetSmoothCalib(&RTCHandle, RTC_SMOOTHCALIB_PERIOD_32SEC, RTC_SMOOTHCALIB_PLUSPULSES_SET, (uint32_t)(512-LSEcalibrationvalue)) != HAL_OK) {
      // handle error
    }
  }
  else {
    if (HAL_RTCEx_SetSmoothCalib(&RTCHandle, RTC_SMOOTHCALIB_PERIOD_32SEC, RTC_SMOOTHCALIB_PLUSPULSES_RESET, (uint32_t)abs(LSEcalibrationvalue)) != HAL_OK) {
      // handle error
    }
  }
}

The function inserts or masks ticks from the LSE over each 32s period (max -511 +512 iirc)

9

Hi,
Thank you again for your kind assistance :slight_smile:

What do you use as a good source generally?

Andy

10

PCF8563T normally but once I'm satisfied with GIGA RTC calibration I'll just use ntp

11

Very interesting. I infer from that these initial calibrations stable enough to put into production and subsequently rely on NTP data. Correct?

12

Too early to say for sure, but that's the plan. My 12 days since sync are up tomorrow, at which point I'll measure the drift and apply the calibration. I will re-apply the calibration each time I use ntp as this will hopefully be rarely but would be needed if the rtc batt is disconnected.

I'm running this process across 3 boards. Once the calibration values are set I'll monitor for drift. I plan to post a how-to on this once I'm confident it works.

13

Having run my uncalibrated giga (first edition) for around 8hrs I observe 20-60ms adjustments each NTP sync (which is every 5 mins). This is a lot of drift (1.2s every 2hrs at 50ms). It’s always faster. I am reasonably confident that this drift is the giga because I measure packet one way latency to a NTP sync’d server using a variety of timestamps and those measurements are a sawtooth (as you’d expect) where the latency numbers are sensible just after NTP sync (I’ve done a lot of performance sensitive network programming so I have good intuition about RTT on a function WAN plus) and sometimes negative just before the next one. If it was the server having a time issue the sawtooth would have a start point out of sync with the giga NTP sync. I also time from that server to the next with an operation which is strictly upper bounded at roughly 1s and that’s what get consistently.

I am sure this isn’t just drift, no doubt the RTT to NTP is one sided due to interrupts (etc) delaying sends and receives of packets in inconsistent manners. I run a single thread and I block for NTP responses (this doesn’t particularly seem to matter, if I do non-blocking and check back each loop the results are similar). .

I am using NTP fractional offsets and the full calculation.

This isn’t a query comment :). It’s just for the record in case others land here.

14

I’ll be very interested in the drift you are seeing @steve9 before you apply the correction.

15

I'm 8hrs away from final scores-on-the-doors, but after 11 days, 19hrs approx:
+174s
+260s
+192s

16

7 days since applying calibrations and a re-sync with ntp.
RTCs still within 1s of source :slight_smile: This should be the case for at least another 5 days. If so, that's good enough for me

1 Like