UNO R4 WiFi RTC runs fast by about 1 second per minute

I noticed this problem when writing a sketch to run a clock on an epaper display. It seemed to be running fast. Letting it go over night it seemed to go fast by about 1 second per minute. I then went back to the examples for Arduino UNO R4 WiFi : RTC : RTC_alarm. I made a simple change to use the LED Matrix to indicate the alarm, and then timed the duration between alarms using my iPhone clock. Sure enough, each alarm (supposedly 1 minute apart) was 1 second sooner each time.
I then hooked up a DS3231 I had sitting around, set the initial times to the same value on both the R4 RTC and the DS3231, and let the alarm demonstration run. This verified the fact that the alarm went off 1 second sooner than it should have each time it cycled around.
I went on step simpler and took out the alarm process and just went thru 1 minute delay cycles, and saw in the printout that the R4 RTC gains a second every minute.
Trying again with a 15 minute cycle time with this .ino code:

/*
 * This example demonstrates the relative time of UNO R4 RTC vs DS3231
 *
 */

#include "RTC.h"  // R4 RTC
RTCTime currentTime;

#include "RTClib.h"  //DS3231 Adafruit routines
RTC_DS3231 rtc;
DateTime now;

// Using the R4 LED matrix to indicate alarm in place of Portenta C33 built in LEDs
#include "Arduino_LED_Matrix.h"
ArduinoLEDMatrix matrix;
const uint32_t chip[] = {
  0x1503f811,
  0x3181103,
  0xf8150000
};

const uint32_t happy[] = {
  0x19819,
  0x80000001,
  0x81f8000
};


void setup() {
  Serial.begin(115200);
  matrix.begin();

  rtc.begin();
  RTC.begin();

  rtc.adjust(DateTime(2023, 6, 7, 13, 03, 00));  // setting time of DS3231 in the same manor as R4 RTC

  RTCTime initialTime(7, Month::JUNE, 2023, 13, 03, 00, DayOfWeek::WEDNESDAY, SaveLight::SAVING_TIME_ACTIVE);
  RTC.setTime(initialTime);

  now = rtc.now();           // getting time from DS3231
  RTC.getTime(currentTime);  // getting time from R4 RTC
  Serial.println("Initial readout after time set");
  Serial.println(String("DS3231 time: ") + now.timestamp(DateTime::TIMESTAMP_FULL));
  Serial.println("R4 RTC time: " + String(currentTime));
  Serial.println(" ");
}

int cycle_count = 0;
int next_time = millis();
void loop() {
  while(millis()<next_time){
  }
  next_time += 60000*15;  //  one minute
  now = rtc.now();
  RTC.getTime(currentTime);
  Serial.print("15min Cycle number ");
  Serial.println(cycle_count);
  Serial.println(String("DS3231 time: ") + now.timestamp(DateTime::TIMESTAMP_FULL));
  Serial.println("R4 RTC time: " + String(currentTime));
  Serial.println(" ");
  cycle_count += 1;
}

I got the results:
Initial readout after time set
DS3231 time: 2023-06-07T13:03:00
R4 RTC time: 2023-06-07T13:03:00

15min Cycle number 0
DS3231 time: 2023-06-07T13:03:00
R4 RTC time: 2023-06-07T13:03:00

15min Cycle number 1
DS3231 time: 2023-06-07T13:18:02
R4 RTC time: 2023-06-07T13:18:16

My Uno R4 Minima is gaining 2 seconds per minute.

Using the example sketch "RTC_AutomaticExample", here is the output from the serial monitor, with timestamps displayed:

17:57:43.597 -> The RTC was just set to:
17:57:43.597 -> 2023-7-8 17:57:21
17:58:20.424 -> An alarm was triggered at:
17:58:20.424 -> 2023-7-8 17:58:0
17:59:18.255 -> An alarm was triggered at:
17:59:18.255 -> 2023-7-8 17:59:0
18:00:16.124 -> An alarm was triggered at:
18:00:16.124 -> 2023-7-8 18:0:0
18:01:13.925 -> An alarm was triggered at:
18:01:13.925 -> 2023-7-8 18:1:0
18:02:11.764 -> An alarm was triggered at:
18:02:11.764 -> 2023-7-8 18:2:0
18:03:09.605 -> An alarm was triggered at:
18:03:09.605 -> 2023-7-8 18:3:0
18:04:07.450 -> An alarm was triggered at:
18:04:07.450 -> 2023-7-8 18:4:0
18:05:05.314 -> An alarm was triggered at:
18:05:05.314 -> 2023-7-8 18:5:0
18:06:03.164 -> An alarm was triggered at:
18:06:03.164 -> 2023-7-8 18:6:0
18:07:00.999 -> An alarm was triggered at:
18:07:00.999 -> 2023-7-8 18:7:0
18:07:59.017 -> An alarm was triggered at:
18:07:59.017 -> 2023-7-8 18:8:0
18:08:56.711 -> An alarm was triggered at:
18:08:56.711 -> 2023-7-8 18:9:0

The same sketch on my Uno R4 WiFi does not run correctly and only displays:

18:55:10.879 -> A

I am using Arduino IDE 2.1.1

Hi @dklimek1

Looking Arduino R4 Minima and WiFi schematics, neither use an external 32.768kHz crystal on the RA4M1 microcontroller's XCIN/XCOUT pin. This suggests that perhaps the RTC might be using the microcontroller's on-chip, interal 32.768kHz oscillator as a clock source instead? (I haven't looked at the Uno R4's core code).

Using an internal 32.768kHz oscillator instead of an exteranl crystal can lead to a loss of precision, which can be in the region of ±20 minutes per day. Using an external 32.768kHz ±20ppm crystal by contrast, you can expect around ±1.7 seconds per day.

1 Like

Glancing at the spec sheet of the processor , there seems to be a possible adjustment for the RTC .
The quality of the Crystal will have an impact on drift, you can use an external xtal ( bodging needed ?) , the Arduino may use an internal clock source ( guessing here, confirmed by previous poster ) which may not be very accurate ( data sheet recommends external x’tal )

Hi @dklimek1

Looking that the ArduinoCore-renesas code, the RTC is using the internal "LOCO" 32.768kHz oscillator:

rtc_cfg_t rtc_cfg  = { 
    // TODO: change me to RTC_CLOCK_SOURCE_SUBCLK when capacitors are mounted
    // https://arduino.atlassian.net/browse/HWH33-204
    // Fixes counting time in VBAT mode on H33
    // Leave as is for Santiago
    .clock_source = RTC_CLOCK_SOURCE_LOCO,

This can be found on line 451 in the RTC.cpp file here: https://github.com/arduino/ArduinoCore-renesas/blob/main/libraries/RTC/src/RTC.cpp

The rtc_cfg structure is passed as a reference to the rtc_init() function a few lines down at line 469, before in turn calling on the Renesas FSP library's R_RTC_OPEN():

static void rtc_init(void) {
  if(!rtc_ctrl.open) {
    R_RTC_Open(&rtc_ctrl, &rtc_cfg);
  }
}

Looking at the Renesas RA4M1 datasheet, section 48.3.2 Electrical Characteristics - Clock Timing (page 1330), it can been seen that the "LOCO clock oscillation frequency" is nominally 32.768kHz, but can actually vary between 27.8528kHz and 37.6832kHz. The datasheet doesn't say, but I assume that it's likely that this test was conducted over a -40°C to +85°C range, so is almost certainly represents the worst case scenario. However, you can see where this is going:

Variation in frequency:

32768Hz - 27852.8Hz = 4915.2Hz
37683.2 - 32768Hz = 4915.2Hz

There are 86400 seconds in a day, therefore:

±4915.2Hz / 32768Hz * 86400s = ±12960 = ±3.6 hours per day (3 hours 36 minutes)

By contrast a 32.768kHz external crystal at ±20ppm @ 25°C will typically exhibit approximately ±400ppm over the same -40°C to +85°C range:

Variation in frequency = f * ppm / 1e6 = 32768 * ±400 / 1000000 = ±13.1072Hz

±13.1072Hz / 32768Hz * 86400s = ±34.56 seconds per day

For a 32.768kHz external crystal ±20ppm @ 25°C, it's 1.728 seconds per day

The point here is that the microcontroller's internal oscillator's precision can't match that of an external crystal.

Personally, I do find it particularly odd that Arduino advertise the fact that the Uno R4 includes an RTC and go to the trouble of writing the support code for it, only to omit the external 32.768kHz crystal that would actual make it, precision-wise at least, actually useful.

I guess there's always the option of using an external RTC.

2 Likes

Is there anywhere a Crystal could be neatly fitted and are the connections reachable ??

I’ve got all excited and just ordered an R4 - not good to claim a RTC if it’s no better than millis !

Hi @hammy

Unfortunately, there doesn't appear to be any provision for retrofitting the crystal with unpopulated pads. The microcontroller's XCIN and XCOUT pins remain unconnected on both the Uno R4 WiFi and Minima:

image

1 Like

After finding out how inaccurate the RTC was, I decided to check how accurate or not "millis" was on the Uno R4.

I put together a quick sketch, based on BlinkWithoutDelay to increment a counter and print it's value to the serial monitor once per hour.

const int outputPin = 12;
int outputState = LOW;
unsigned int count = 0;
unsigned long previousMillis = 0;
const long interval = 1800000;

void setup() {
  pinMode(outputPin, OUTPUT);
  Serial.begin(115200);
}

void loop() {
  unsigned long currentMillis = millis();
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    if (outputState == LOW) {
      outputState = HIGH;
      Serial.println(count);
      count++;
    } else {
      outputState = LOW;
    }
    digitalWrite(outputPin, outputState);
  }
}

I left it running overnight, and here are the results:
Screenshot 2023-07-09 092525
The timestamps show that the "millis" keeps good time.

So based on a sample of one, "millis" keeps time better than the RTC.

1 Like

That's presumably because there is at least a resonator if not a crystal for the main processor clock.

As you have the WiFi version you could synch up with NTP to get accurate time?

1 Like

I made a simple clock using the Sparkfun RTC that is powered with a capacitor. With the Qwiic port on the R4 WIFI its plug and play and it will keep time for 30 days with no power. I'm testing that now. It was easy enough to display the time on the LED Matrix. The most accurate RTC I've used is the Chronodot. My testing shows less than 1 sec per month accuracy but it takes some wiring and a breadboard. I'll live with the less accurate Sparkfun since I don't have to keep track of coin cell voltage and simple 1 cable hook up. Make sure you switch to Wire1 in the code (see theread)

Thanks for the millis test.

My UNO R4 WiFi Real Time Clock also runs fast by about a second per minute.
On page 555 of the Renesas Hardware manual, there is a register RADJ to adjust the real time clock.
Does anyone know how to do this?
Jim

Thanks for the info

The GIGA R1 RTC is wonky also.

I was able to tighten up what the R4's RTC is reporting by changing the frequency compare value to 261 (0105h) from what is given in the RTC.cpp referenced in above snippet, just a few more lines down.

I referenced the above cited R4 user manual, section 24.2.20.

It's a really rough adjustment but may lower the frequency of one's needing to hit up the NTP.

Mark

I have 2 Uno R4 WiFi controllers. Both have the most inaccurate RTC I have ever tested. One has gained 10 minutes in the past 4 hours. the other has gained 6 minutes in the past 3 hours. This fact makes the RTC virtually unusable. How can Arduino release such a poorly designed RTC. We purchase genuine Arduino controllers because we want the best. This flaw was completely unexpected.

2 Likes

You can make it better using an external, DS3231 based, RTC :grin: :grin: :grin:

The UNO R4 WiFi is a board without a crystal for the RTC, without a crystal for the main clock and, apparently, (see HERE) with a practically useless RTC ... :confused:

Guglielmo

2 Likes

I went a different way ... I used a GPT timer, and by experimentally adjusting the frequency I got an error of ± 1 sec. over 24 hours ... still a lot compared to an external RTC, but infinitely better than with the internal RTC. :roll_eyes:

Guglielmo

1 Like

Hello, I just bought a Uno R4 wifi and started testing the RTC last night and I can confirm that it appears to be wildly inaccurate. In about four hours its fast by six minutes. I simply used the code Arduino provides for the RTC, and made a simple sketch just to test its functionality, and then as an aside to simply see how it tracks the computer time, and I am really disappointed. I was fully expecting it to be very accurate.

Which is why I then searched for accuracy issues with the RTC only to find this page. So it seems my experience is common. I don't have any specific application for the RTC at the moment, but I am REALLY disappointed that it is not as advertised by Arduino. I am quite willing to buy Arduino original HW to support them, but I wont do this if they products are not what they say they are. I am kind of shocked.

Now IF I do need an RTC at some time, I will have find another solution. Not cool.

Steven Lightfoot

4 Likes

Update: I contacted Arduino yesterday, they said they are aware of the issue and are working on fix, its not clear to me if its a SW or library type fix or a hardware fix (which would mean a sub-revision to the Rev 4 wifi board, which I am sure they are keen to avoid). They said pay attention to the RTC Renasas library Github, so I signed up for notifications. I have no sense of timelines, but at least they are attempting to do something. I really wanted an accurate RTC on the Uno Rev 4 wifi. Steven Lightfoot