One of the things my R4 WIFI does is control lighting based on time (even as an alarm clock), and the drift meant I had to reupload every night and it would still be off by ~5 minutes in the morning.
I added CAC_Correction yesterday, and this morning the drift was too small to tell, less than a minute. Which is already good enough, though I'll have to record some numbers to be more accurate.
Data from my R4 WIFI.
TL/DR: seems to be around 4.44 minutes lost per week. Jump to the right-most columns.
| i date | init PC | init RTC | i dif | end date | end PC | end RTC | e dif | slip | dur s | s slip/h | s/day | min/w |
| 20231122 | 14:40:27 | 14:39:58 | 29 | 20231124 | 17:22:52 | 17:20:49 | 123 | 94 | 182545 | 1.854 | 44.49 | 5.19 |
| 20231124 | 17:25:05 | 17:24:48 | 17 | 20231126 | 17:06:38 | 17:05:05 | 93 | 76 | 171693 | 1.594 | 38.25 | 4.46 |
| 20231126 | 17:07:33 | 17:07:15 | 18 | 20231204 | 17:57:34 | 17:52:10 | 324 | 306 | 694201 | 1.587 | 38.08 | 4.44 |
The plan is to reset weekly, so I'm not sure I'll be getting better data.
I continue to really like this. It turned a practically unusable RTC into something that works just fine if I set the clock once a week. Maybe I'll buy a more accurate RTC eventually, but right now I'm still making the occasional setting change anyway, so pacing those out at once a week is really good.
By attaching a clock crystal oscillator to pins 6 and 7 of RA4M1 and rewriting RTC.cpp, I was able to reduce the RTC deviation to within 1 second per day.
Specifically, "define RTC_CLOCK_SOURCE RTC_CLOCK_SOURCE_LOCO" on line 455 of RTC.cpp was rewritten to "define RTC_CLOCK_SOURCE RTC_CLOCK_SOURCE_SUBCLK."
Is there a way to manipulate the clock switching register within the sketch without rewriting this RTC.cpp?
Well done! Does that much improved performance also apply when the power is off and the RTC is running on Vrtc (i.e. does it continue to use the crystal on battery backup)?
I made a new topic because I gave the wrong reply.
"How to correct the UNO R4 RTC time difference".
I'm currently backing it up with a battery and checking it out. I will post the results in a new topic.
Hi @JohnLincoln, in order to test this PR you have to download my fork of the core from here. By following this guide you can install it on your local machine. Then run your sketch and check if it satisfies your requirements.
If you don't have a sketch, you can run the examples, under the RTC library, the best suited one is this one. I expect it to work this way:
When run the first time it will set the RTC register with the compile time timestamp
If I press reset on the board, the RTC will preserve the last value present on the board
If I power the VRTC pin with 3.3V, then I detach the board from usb connection, I keep it running for some time, I reattach it to the USB interface and I will see that the time kept on going from where it left
If I detach the board, without powering VRTC, when reattaching it the board will show the timestamp that was set during compilation time
The fix linked addresses the issue for which the RTC doesn't keep its value after a reset, it doesn't deal with its precision.