Rough fix for the RTC

Hardware UNO R4 UNO R4 WiFi
1

Hello --

I just started tinkering with the UNO R4's RTC couple days ago and found major time reporting error, running fast, just the like the GIGA R1's on-board RTC.

The R4's RTC is running off the internal LOCO oscillator, as defined in the RTC library. From the RA4M1 user manual, in section 24.2.20, it seems one can change the frequency compare value to make adjustments, and fortunately this compare value can be changed in the RTC.cpp. I have set this value in the RTC.cpp, line 455, to 261 (0105h), from the default 255 (00FFh), effectively slowing the RTC from gaining an hour in a day to something like few minutes per day. I might try setting at 262 and see what happens over coming days.

The range for frequency compare value can be 0-511 (CORRECTION: 7-511, from the FSP manual), so one can plug in numbers and see the effect. Raising the value slows the clock &v.v. A rough napkin calculation showed my clock beating at about 129.2 Hz, maybe.

Some folks willing to try this fix and tell me why this is good/bad idea, and perhaps report results if the fix is attempted?

Thank you,
Mark

2

This sounds like worse timekeeping even than you would get even from an old mechanical, wind-up clock. I suggest you invest in a DS3231.

1 Like
3

Following up with adjusting the frequency compare value to 261, I then set to 262 and let run for a while. I found that a frequency value of 261 let the RTC run fast, gaining about 1.92 min/day, while the value 262 let the RTC run slow, losing about 3.6 min/day.

These values are acceptable, given that originally I was looking at having to hit up NTP every hour for a time correction. Now I may relegate that to a daily update.

4

This gets a little bit closer by swapping between the two values to try to compensate.

5

I just checked the RTC error on R4wifi, and read some tips to fix it.
Many years ago, I had to have (on UNO or MEGA) a valid measure of time, RTCs were pretty new and I didn't want to be blacklisted on an NTP, so I relied on millis() which can be corrected very precisely.
Using epoch from NTP at startup and adding millis()/trim, the clock was perfect, and when millis() reached overrun, an NTP call was made to synchronize.
If the NTP call failed, epoch was updated by the value of MAXmillis()/1000. Got epoch, my schetch obtained Data & time.

Today, you can sync the UnoR4's RTC every minute with epoch obtained as above, and RCT will always be accurate.
I don't know if this has already been written, and if so .