System time on WiFi Rev2 is on steroids

I have two UNO WiFi Rev2s and I monitor the system time on both. One of them is very consistent in keeping close to the actual time using Epoch time as a reference.
The other one is a different matter. In the 5 hours since the program started and had the system time initially set it has already advanced ahead of Epoch time by about 18 seconds. I can deal with this but the accuracy difference between the two is considerable. Is this due to the crystal or its associated circuitry? I know back in 2019 there was a component issue related to the crystal:

https://github.com/arduino/ArduinoCore-megaavr/issues/27

But both my Arduinos are only a couple years old and should not be included in that manufacturing blip.
I am not in any way learned on microprocessor hardware design but was wondering if after setTime() completes an update to the processor is millis() responsible for the time advancement and does this in conjunction with the crystal?

EDIT: I realize you are using a WiFiRev2 and I believe that there is a crystal on that device. I'm not certain what the specification is.

Correct, but with the Nano Every there is no external crystal oscillator but an internal oscillator. (OSC20M) This system clock is divided down to run TimerB3 which is the timer used by millis( )

From my review of the data sheet, I believe the spec on the OSC20M oscillator is +/- 2% so if you are seeing 18 seconds in 18000 seconds you are well within spec. There are registers for setting a calibration of the main clock, but you will need to spend some time deep in the data sheet for the 4809 to figure it out.

Yes, it has a crystal but like you I am unaware of the spec.

I believe that the crystal connected to TOSC1 and TOSC2 on the wifi rev 2 is used for the RTC clock and is not the main system clock.

I think the main system clock is the internal oscillator and is either running at 16MHz or 20MHz with the 2% spec.

There is a separate 16MHz oscillator or crystal on the 32U4 chip uses as the USB interface, but it is not the system clock for the 4809.

I just went ahead and made the "fast" UNO get epoch time once an hour and update the system time with the setTime function.

We have discussed this previously, but you may you may want to explore using the fork of the time library which uses the 4809 real time counter driven by the crystal instead of the system clock and the millis() timer.

https://github.com/goodchip/Time

The maintaining of two code bases with different update times, may make it worthwhile to consider the change to the library fork.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.