Re: Can we fix the RTC?

This is great! Huge improvement for my R4 WIFI.

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.

This Arduino UNO R4 WiFi VRTC & OFF Pins | Arduino Documentation might be helpful.

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.

Thank you for making this, I appreciate it.

This is my first time posting on the forum.

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?

I'm using Google Translate.

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)?

It seems I wrote it wrong. I'm sorry.

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.

I read this thread looking for possible RTC solutions. Great work.

I’m studying the R4 WiFi onboard ESP-32 literature to determine if it’s possible to use its RTC.

https://www.espressif.com/sites/default/files/documentation/esp32-s3-mini-1_mini-1u_datasheet_en.pdf#page520

https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf#page520

What’s the RA4M_Bridge (direct) interface between the two? Serial? Is the protocol documented?

This is really interesting.

One baked-in AT command already exists to get Unix time from the ESP. Resolution is in seconds, but no firmware update should be needed.

AT+SYSTIMESTAMP?

However, there’s also this one:

AT+SYSREG

AT+SYSREG=direct, address (,write value)

direct: read or write register (0 or 1)
address: (uint32) register address.
write value: (uint32) write value (only in write mode).

This might generally allow peripheral register retrieval and modification. Again, no firmware update needed.

So! It took some time but we have a pull request that fixes the RTC issue:

Can anyone help testing this?

I'll help testing, if you can explain what I have to do.

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.

1 Like

Thank you for those instructions,
I will give it a try, and report back later.

1 Like

Hello @agilardoni, I tried to follow the guide from your link, but I had a problem when it came to stage 3. Installing the ArduinoCoreAPI.

I'm using Windows, and have both Arduino IDE 2.3.2 and Arduino IDE 1.8.19.

It is the last line on the screenshot below that I had problems with.

I assume that <ArduinoCore-API_path> is the path to the files that I have just downloaded, but what is the path <core_path> ?

The fix is now included in the newly released core version 1.2.1. Hope it works!

When is this scheduled for release? It will show up as a new version in Boards Manager, right?
Thanks!

Hi all. The 1.2.1 release of the "Arduino UNO R4 Boards" platform is now available for installation via the Arduino Boards Manager.

1 Like