Arduino UNO R4 RTC Guide: Clock, Alarms, Backup Power and Timekeeping

The Arduino UNO R4 WiFi and UNO R4 Minima both include a hardware real-time clock inside the Renesas RA4M1 microcontroller.

That means you can keep track of:

• seconds;
• minutes;
• hours;
• day;
• month;
• year;
• day of week;
• alarm events;
• periodic time-based callbacks.

The RTC can continue running while the main 5 V board supply is removed if the VRTC backup pin is powered separately.

On the UNO R4 WiFi, Arduino documents a VRTC backup range of 1.6 V to 3.6 V. This allows a small backup source to keep the RTC domain alive while the rest of the board is off.

This guide explains how to initialise the RTC, set and read time, use alarms, create periodic callbacks, preserve time during power loss, synchronise the clock from NTP on UNO R4 WiFi and avoid common timekeeping mistakes.

UNO R4 RTC at a Glance

Feature	UNO R4 WiFi / Minima
RTC hardware	Built into Renesas RA4M1
Arduino library	RTC.h
Calendar time	Yes
Day of week	Yes
Alarm callback	Yes
Periodic callback	Yes
Unix time conversion	Supported through RTCTime
Backup supply	VRTC pin
UNO R4 WiFi VRTC range	1.6–3.6 V
Network time sync	Easy on UNO R4 WiFi using Wi-Fi + NTP
External RTC required	No for normal timekeeping

Why Use the Built-In RTC?

Older Arduino projects often used an external RTC module such as the DS1307 or DS3231.

On UNO R4, a separate RTC is not necessary for many projects.

The internal RTC is useful for:

• data logging;
• time-stamped sensor readings;
• scheduled automation;
• alarms;
• clocks;
• lighting schedules;
• machine run-time logging;
• daily maintenance counters;
• periodic wake or service events.

The main reason to add an external RTC now is usually not “because the R4 has no clock”. It is because you need something more specialised, such as:

• better long-term absolute accuracy;
• temperature-compensated timing;
• larger backup battery arrangements;
• special alarm outputs independent of the MCU;
• a design already standardised around an external RTC.

Include the RTC Library

The UNO R4 RTC library is included in the Arduino Renesas board package.

Start with:

The global RTC object is then available as:

Initialise the RTC

Call:

normally from setup().

Example:

RTCTime Object

Arduino represents date and time using the RTCTime class.

A complete date/time object can contain:

• day of month;
• month;
• year;
• hour;
• minute;
• second;
• day of week;
• daylight-saving status.

A typical constructor looks like:

Set the RTC Time

Once the RTC has been initialised:

Complete example:

Do not leave hard-coded time-setting code permanently in setup() unless you really want the RTC reset to the same date after every restart.

A Common Mistake: Resetting the Clock at Every Boot

This code:

always overwrites the retained RTC time when the Arduino restarts.

If the VRTC backup supply has correctly preserved time, that defeats the entire point of backup power.

A better design is to set the RTC only when:

• the clock has not been initialised;
• the user explicitly requests a time update;
• network synchronisation succeeds;
• a configuration command supplies a new time.

setTimeIfNotRunning()

The current RTC library includes:

This can be useful when you want to initialise a clock only if the RTC is not already running.

For example:

This is safer than unconditionally resetting the time at every boot.

Read the Current Time

Create an RTCTime object and pass it to RTC.getTime():

You can then read individual fields:

Basic Clock Example

Print Date and Time

A more complete example:

RTCTime String Conversion

The current UNO R4 RTC library can also convert an RTCTime object into an ISO-like string.

Internally it produces a format similar to:

This is useful for:

• serial logging;
• CSV files;
• HTTP requests;
• MQTT payloads;
• human-readable diagnostics.

Unix Time

RTCTime also supports Unix-time conversion.

You can obtain:

Unix time is useful when:

• storing timestamps efficiently;
• comparing time intervals;
• communicating with web APIs;
• working with NTP;
• sorting logged events.

Calendar Time vs millis()

Do not confuse RTC time with millis().

millis() answers:

The RTC answers:

Use millis() for short-term scheduling inside a running program.

Use the RTC for:

• calendar events;
• wall-clock time;
• timestamps;
• daily schedules;
• retaining time through resets and power interruptions.

VRTC Backup Power

The UNO R4 WiFi exposes a VRTC pin.

Arduino documents a backup voltage range of:

When the main board power is removed, a suitable voltage on VRTC can keep the RTC domain alive.

The important distinction is:

The CPU, Wi-Fi module, GPIO and other peripherals do not continue normal operation from VRTC.

Backup Supply Options

Possible RTC backup sources include:

• a small lithium coin cell, if the voltage and charging arrangement are appropriate;
• a supercapacitor;
• a regulated backup rail from the host equipment;
• a small dedicated battery system.

Do not connect a rechargeable battery to a circuit that is not designed to charge it.

Similarly, do not apply more than the permitted VRTC voltage.

CR2032 Warning

A CR2032 coin cell has a nominal voltage around 3 V, which sits within the VRTC voltage range.

However, the electrical implementation still matters.

You should:

• ensure there is no unintended charging current into the coin cell;
• check polarity carefully;
• avoid wiring a battery directly into another powered rail;
• follow the board schematic when designing a permanent backup circuit.

How Long Will a Backup Cell Last?

RTC backup current is typically very small compared with the rest of the board.

Actual lifetime depends on:

• battery capacity;
• self-discharge;
• temperature;
• the exact backup-domain current;
• leakage in your external circuit.

For a well-designed backup circuit, the RTC can usually be preserved for a very long period compared with ordinary MCU runtime.

Does the RTC Keep Time During a Reset?

A normal processor reset does not necessarily mean the RTC loses its time.

The RTC is a separate hardware peripheral and can continue running as long as its clock domain remains powered and configured.

The bigger risk is your own firmware overwriting it again during setup().

RTC Alarms

The Arduino RTC library supports calendar alarm callbacks.

The basic sequence is:

1. create an alarm time;
2. create an AlarmMatch object;
3. choose which fields must match;
4. register a callback.

AlarmMatch Fields

The current library supports matching on:

• second;
• minute;
• hour;
• day of month;
• month;
• year;
• day of week.

For example:

Current library code supports multiple simultaneous match fields.

One-Time Alarm Example

Keep Alarm Callbacks Short

The callback is associated with RTC interrupt handling.

Do not perform long blocking work inside it.

A good pattern is:

Then perform the actual work in loop().

Avoid doing things such as:

• long delays;
• large Serial prints;
• network connections;
• file writes;
• complex calculations;

directly inside the interrupt callback.

Daily Alarm Example

If you want an event every day at 07:30, match only hour, minute and second:

Because the day, month and year are not part of the match, the alarm can trigger each day when the time fields match.

Weekly Alarm

You can also include the day of week.

For example:

This is useful for weekly schedules.

Periodic Callbacks

The RTC library also supports periodic callbacks independent of a specific calendar time.

Current period options include:

• once every 2 seconds;
• once every 1 second;
• 2 times per second;
• 4 times per second;
• 8 times per second;
• 16 times per second;
• 32 times per second;
• 64 times per second;
• 128 times per second;
• 256 times per second.

This is hardware RTC periodic-interrupt functionality, not a replacement for every timer use case.

One-Second Periodic Callback Example

When to Use RTC Periodic Callbacks

They are useful for:

• one-second clock updates;
• low-rate counters;
• periodic housekeeping;
• time-based state changes;
• simple scheduler ticks.

For microsecond-level timing or high-speed control loops, use the RA4M1 timers instead.

Set the RTC from NTP on UNO R4 WiFi

UNO R4 WiFi can obtain accurate network time because its ESP32-S3 provides Wi-Fi.

A typical architecture is:

This is useful because the board does not need to remain permanently dependent on the network once the RTC has been synchronised.

Arduino’s NTP Example

Arduino’s current Renesas RTC examples use:

• WiFiS3.h;
• WiFiUdp.h;
• NTPClient.h;
• RTC.h.

The NTP client obtains Unix time from an internet time server and that value can then be converted into an RTCTime and written to the hardware RTC.

Simple NTP Sync Pattern

In a real application, also handle:

• Wi-Fi connection failure;
• NTP timeout;
• timezone offset;
• daylight-saving rules;
• periodic re-synchronisation.

UTC Is Usually the Best RTC Storage Format

For connected devices, a good design is to keep the hardware RTC in UTC rather than local civil time.

Then apply timezone and daylight-saving rules only when displaying the time.

This avoids the RTC itself jumping forward and backward during daylight-saving transitions.

For example:

depending on timezone and daylight-saving rules.

SaveLight Is Not a Full Timezone Engine

The RTCTime object includes a daylight-saving state:

That does not automatically calculate regional daylight-saving transitions for you.

Rules differ by country and can change over time.

If your project needs correct civil time globally, use a proper timezone implementation or keep the RTC in UTC and let a network-connected application handle local conversion.

How Often Should You NTP Sync?

For a connected UNO R4 WiFi, you do not need to query an NTP server every second.

A sensible design might synchronise:

• at boot;
• once per day;
• every few hours;
• after a long power outage;
• when the user requests it.

The correct interval depends on the drift of your RTC and the accuracy required by the application.

RTC Drift

No hardware RTC is perfectly accurate.

Its clock source can drift with:

• temperature;
• manufacturing tolerance;
• aging;
• supply conditions.

Even a small frequency error accumulates over time.

For example, an error of 20 parts per million corresponds roughly to:

This is only an illustration of how ppm translates into elapsed-time error; the actual UNO R4 drift depends on the clock source and operating conditions.

Measure Your Own Drift

If timing accuracy matters, test the actual board.

A practical method is:

1. synchronise the RTC from NTP;
2. leave the board running for several days;
3. compare the RTC against an NTP or GPS reference;
4. calculate seconds gained or lost per day.

This gives you the effective drift of your complete system under realistic conditions.

When an External DS3231 Still Makes Sense

The DS3231 remains popular because it is a temperature-compensated RTC designed specifically for stable timekeeping.

Use an external DS3231 when:

• long-term offline accuracy matters more than integration;
• network time is unavailable;
• temperature variation is large;
• you want a proven removable coin-cell backup system;
• you are migrating an existing DS3231-based design.

For many networked or general-purpose R4 projects, the built-in RTC is simpler and perfectly adequate.

RTC for Data Logging

A typical logger flow is:

For example:

Time-stamped data is much easier to analyse later than records based only on millis().

RTC for Scheduled Automation

The R4 can easily control:

• lighting schedules;
• irrigation;
• heating;
• ventilation;
• daily machine tests;
• scheduled data uploads.

For example:

Use alarms or compare RTC time in the main application loop.

Alarm or Polling?

Both approaches are valid.

Alarm Callback

Useful when:

• an event should occur at a specific time;
• you want hardware-supported matching;
• the MCU may be doing other work.

Polling

Useful when:

• the main loop already runs frequently;
• the schedule is complex;
• you need several independent events;
• you prefer keeping all application logic outside interrupts.

A simple scheduler can read the RTC once per second and compare against a table of events.

Avoid Triggering the Same Event Repeatedly

If you poll like this:

and the loop runs thousands of times during that minute, the function may execute repeatedly.

Add a latch or compare seconds:

Then clear the latch when the time moves out of that trigger window.

RTC and Power Loss

Think of three different situations:

Situation	Expected result
Main power on	RTC runs normally
Main power off, VRTC maintained	RTC can continue retaining time
Main power off, no RTC backup	Do not rely on time being preserved indefinitely

If your project must always recover correct time after a long outage, combine backup power with a network or user-based resynchronisation strategy.

RTC and UNO R4 WiFi vs Minima

The RTC hardware comes from the same RA4M1 family, so the software model is essentially shared across the two R4 boards.

The major practical difference is synchronisation.

UNO R4 WiFi

Can obtain time directly from:

• NTP servers;
• internet APIs;
• Arduino Cloud;
• local network services.

UNO R4 Minima

Has no onboard network radio, so time can be set from:

• USB serial;
• an external GPS module;
• an external network module;
• a host computer;
• manual configuration.

If you are choosing between the two R4 models, see our UNO R4 WiFi vs UNO R4 Minima comparison.

RTC and UNO R3

The classic UNO R3 has no comparable built-in calendar RTC.

That is one of the less obvious but useful improvements in the R4 generation.

For the full generational comparison, see our Arduino UNO R4 vs UNO R3 guide.

Common RTC Problems

1. Time Resets Every Boot

Check whether your sketch calls RTC.setTime() unconditionally in setup().

2. Time Is Lost After Power Removal

Check the VRTC backup source, wiring and voltage.

3. Time Is Off by One Hour

This is often a timezone or daylight-saving issue, not an RTC hardware fault.

4. NTP Time Is Correct but Displayed Local Time Is Wrong

NTP normally works from UTC. Apply the correct timezone offset and daylight-saving rules separately.

5. Alarm Fires More Often Than Expected

Check which AlarmMatch fields you enabled. If you match only the seconds field, the alarm can match every minute when that second occurs.

6. Periodic Callback Behaves Badly

Keep interrupt callbacks short. Set a flag and handle serial output or heavy work in loop().

Recommended RTC Design Pattern

For a robust UNO R4 WiFi application:

For Minima, replace NTP with the time source available to your application.

Final Thoughts

The UNO R4’s built-in RTC is one of the board’s most useful quality-of-life improvements over the UNO R3 generation.

The key features are straightforward:

• calendar date and time;
• day-of-week handling;
• alarm callbacks;
• periodic callbacks;
• Unix-time conversion;
• backup-power support through VRTC.

On UNO R4 WiFi, the RTC becomes especially useful because Wi-Fi makes NTP synchronisation easy. A good design is to synchronise occasionally from the network, then let the hardware RTC continue locally.

The most important practical rules are:

1. do not overwrite the RTC with a hard-coded time every boot;
2. use VRTC if the time must survive main-power loss;
3. keep interrupt callbacks short;
4. store UTC where possible and apply local timezone rules separately;
5. re-synchronise periodically if long-term absolute accuracy matters.

For general clocks, data loggers and scheduled automation, the built-in RTC means an external RTC module is no longer automatically required on the UNO platform.