[Mark Solved / Archieved] Witty Pi 4 L3V7: looses time 10sec per day

The I2C register No.37 is to store the offset value for RTC calibration. Usually this value has been properly set in the factory, but it can be lost if firmware was updated without keeping the EEPROM values, or the device has been working undervoltage.

It is possible to calibrate the RTC again by measuring the CLKOUT frequency in (unpopulated) P5 header, or count the actual time drift.

Here is an excel file that can calculate the offset value for I2C register No.37:
WittyPi_RTC_Calibration.xlsx

This Excel file provides two approaches (by frequency or by time drift) to calculate the offset value. Properly setting the I2C register No.37 will make the RTC accuarate.

Posted by: @admin

↑

The I2C register No.37 is to store the offset value for RTC calibration. Usually this value has been properly set in the factory, but it can be lost if firmware was updated without keeping the EEPROM values, or the device has been working undervoltage.

It is possible to calibrate the RTC again by measuring the CLKOUT frequency in (unpopulated) P5 header, or count the actual time drift.

Here is an excel file that can calculate the offset value for I2C register No.37:
WittyPi_RTC_Calibration.xlsx

This Excel file provides two approaches (by frequency or by time drift) to calculate the offset value. Properly setting the I2C register No.37 will make the RTC accuarate.

@yww What value have you written into register #37? 

What command did you use and what output did you get?

Posted by: @admin

↑

@yww What value have you written into register #37? 

What command did you use and what output did you get?

@yww why did you use the wrong index 54 and 55? The correct index is 37, or heximal 0x25. There is listed example in that excel file.

And why did you use the wrong value '0'? There is no way this offset value goes to zero. It is usually a value between 0x70~0x80.

You can't expect a good result by writing a wrong value to a wrong register.

If you can't figure out how to use that excel file, you may just run the command below and it should be better than nothing.

i2cset -y 1 8 37 0x77

Hello @uugear
I have a similar issue (but even worse) with a Witty pi 4 Mini (Version 4.21 of the firmware): ~18 minutes of delay (RTC too slow) over 9 days (234 hours) => -1271.37ppm.
I have measured the clockout with an oscilloscope and I get a frequency of 32750 Hz => -549.32ppm.
I have checked i2cget -y 1 0x08 0x25 and the result is 0x79

Putting any of this value in your spreadsheet is beyond the applicable correction.

Your spreadsheet do mention to send "i2cset -y 1 8 54 0" and "i2cset -y 1 8 55 0"  to "fix it" but since you were suggesting that we should not do that, I not tried it yet.

The power supply (5V) was constantly applied to the witty pi mini during this period via a polulu DC-DC converter

Any suggestion?

thanks

How do you measure frequency to any sort of accuracy with an oscilloscope?

@arjenr oscilloscope is not good for such work, you need a frequency counter, or you could just count the time drift.

Hello 

Thanks for your replies.
You are probably both right about the oscilloscope. I retried measuring on my oscilloscope (I do not have a frequency counter at hand) measuring over 64 cycles (rising edge to rising edge at 500Mps) and estimating the average period and I get a lot closer to 32767.42 Hz. So maybe it is not the clock frequency the issue.

I still cannot make the reason for such a long time offset after 9 days of ticking unattended. The wittypi was permanently powered up with a 12V battery, a Pololu 9-36V to 5V regulator and a solar panel.
The Rpi was asleep for the whole 9 days and due to wake up on 9 March at 11:58 UTC (RTC was synchronised with internet prior to shut down on 27 Feb at 18:01 UTC - see log below), but it did not meet the rendez-vous on 9 March.

When I noticed that, about 10 minutes after the expected rendez-vous, I powering it manually (via the toggle switch), the RTC did set the system clock at bootup, then my NTP server updated the system time and showed me a 18 minutes jump.
I forgot to check the RTC time once I noticed that jump. But I can assure you that it was a lot of minutes behing, since at approximately 12:10 UTC the Rpi time at boot up showed 11:52

You can see below the wittyPi.log of this boot and the previous one.

Note : I do not know why the RTC and System report 25s to 38s difference after each boot up even before the Rpi is connected to internet and the system time was set via wittyPi from the RTC. This is not too much of a problem, but it is annoying.
Note 2: I have added a sanity check of the systemtime and RTC time before and after I perform my time update on afterStartup.sh 
Note 3: "Mon 9 Mar 12:10:07 UTC 2026 - Battery voltage: 12.43V" is the first execution of afterStartup.sh. This is how I noticed the system time jump (due to my NTP being active at that moment). At the moment I do not have a recording of the RTC time at that moment in my log. So I am not exactly sure (+/- 2 minutes) of the RTC delay, but you can notice that on 27 February it happened less than 1 minutes after the "Schedule next startup at: ..." line, so I assume that on 9 March it must have been the same => therefore about 18 minutes of delay on the RTC.

Is there a way (maybe via the flashing LED) to assess the "precision" of the clock without powering it? If I set the LED to flash every 5minutes will it be synchronised to the RTC clock or would it happen at a random starting time and then every 5 minutes? Comparing that visually with a GPS clock will allow to confirm if we are with 1-2s of the correct time (modulo 5 minutes).

Any thoughts

Thanks

[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.21) is started.
[xxxx-xx-xx xx:xx:xx] System: Raspbian GNU/Linux 13 (trixie), Kernel: Linux 6.12.47+rpt-rpi-v6, Architecture: armhf
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] RTC offset register has value 0x79
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2026-02-27 17:59:28] Done :-)
[2026-02-27 17:59:28] Firmware ID: 0x36
[2026-02-27 17:59:28] Firmware Revison: 0x05
[2026-02-27 17:59:29] Current Vin=11.82V, Vout=5.02V, Iout=0.38A
[2026-02-27 17:59:31] System starts up because scheduled startup is due.
Fri 27 Feb 17:59:37 UTC 2026 - executing afterStartup.sh
Created symlink '/etc/systemd/system/dbus-org.freedesktop.timesync1.service' → '/usr/lib/systemd/system/systemd-timesyncd.service'.
Created symlink '/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service' → '/usr/lib/systemd/system/systemd-timesyncd.service'.
[2026-02-27 17:59:43] [Warning] System and RTC time seems not synchronized, difference is 37s. System time is "2026-02-27 17:59:43 UTC", while RTC time is "2026-02-27 18:00:20 UTC". Please synchronize the time first.
[2026-02-27 17:59:43] Schedule next shutdown at: 2026-03-02 12:58:00
[2026-02-27 17:59:44] [Warning] System and RTC time seems not synchronized, difference is 38s. System time is "2026-02-27 17:59:44 UTC", while RTC time is "2026-02-27 18:00:22 UTC". Please synchronize the time first.
[2026-02-27 17:59:44] Schedule next startup at: 2026-03-09 11:58:00
Fri 27 Feb 18:00:34 UTC 2026 - Battery voltage: 11.76V
Fri 27 Feb 18:01:00 UTC 2026 - trying to reach internet
Fri 27 Feb 18:01:00 UTC 2026 - internet is reachable
Fri 27 Feb 18:01:00 UTC 2026 - starting upload to UCI
Fri 27 Feb 18:01:44 UTC 2026 - UCI_upload script completed successfully
Fri 27 Feb 18:01:47 UTC 2026 - NTP is synchronized
Fri 27 Feb 18:01:47 UTC 2026 - RTC before: 1772215308 System: 1772215308
Fri 27 Feb 18:01:48 UTC 2026 - updating RTC with System clock
  Writing system time to RTC...
[2026-02-27 18:01:48] Writing system time to RTC...
  Done :-)
<2026-02-27 18:01:50> Done :-)
Fri 27 Feb 18:01:50 UTC 2026 - RTC after: 1772215310 System: 1772215311
Fri 27 Feb 18:01:51 UTC 2026 - updated Witty's RTC
Fri 27 Feb 18:01:56 UTC 2026 - Witty Pi log uploaded successfully.
Usage: gpio mode pin mode
Usage: gpio mode pin mode
/home/pi/wittypi/utilities.sh: line 494: [: ==: unary operator expected
Halting all processes and then shutdown Raspberry Pi...
<2026-02-27 18:01:56> Halting all processes and then shutdown Raspberry Pi...
[2026-02-27 18:01:57] Send out the SYS_UP signal via GPIO-17 pin.
[2026-02-27 18:01:59] Pending for incoming shutdown command...
[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.21) is started.
[xxxx-xx-xx xx:xx:xx] System: Raspbian GNU/Linux 13 (trixie), Kernel: Linux 6.12.47+rpt-rpi-v6, Architecture: armhf
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] RTC offset register has value 0x79
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2026-03-09 11:52:05] Done :-)
[2026-03-09 11:52:05] Firmware ID: 0x36
[2026-03-09 11:52:05] Firmware Revison: 0x05
[2026-03-09 11:52:06] Current Vin=12.49V, Vout=5.02V, Iout=0.25A
[2026-03-09 11:52:07] System starts up because the button is clicked.
Mon  9 Mar 11:52:12 UTC 2026 - executing afterStartup.sh
[2026-03-09 11:52:15] Schedule script is interrupted, revising the schedule...
[2026-03-09 11:52:16] [Warning] System and RTC time seems not synchronized, difference is 25s. System time is "2026-03-09 11:52:16 UTC", while RTC time is "2026-03-09 11:52:41 UTC". Please synchronize the time first.
[2026-03-09 11:52:16] Schedule next shutdown at: 2026-03-09 11:57:00
Created symlink '/etc/systemd/system/dbus-org.freedesktop.timesync1.service' → '/usr/lib/systemd/system/systemd-timesyncd.service'.
Created symlink '/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service' → '/usr/lib/systemd/system/systemd-timesyncd.service'.
[2026-03-09 11:52:18] [Warning] System and RTC time seems not synchronized, difference is 25s. System time is "2026-03-09 11:52:18 UTC", while RTC time is "2026-03-09 11:52:43 UTC". Please synchronize the time first.
[2026-03-09 11:52:18] Schedule next startup at: 2026-03-09 11:58:00
Mon  9 Mar 12:10:07 UTC 2026 - Battery voltage: 12.43V
[2026-03-09 12:11:02] Send out the SYS_UP signal via GPIO-17 pin.
[2026-03-09 12:11:03] Pending for incoming shutdown command...

@nolwenn

Flashing LED is not the right way - the LED is controlled by MCU, which has its own oscillator and has nothing to do with the RTC.

Without a freuency counter, the best way is to count the time drift. Do not schedule any shutdown, just synchronize the time with internet first, and then check back after a long time (longer is better, e.g. one day). Run the wittyPi.sh and you can read the RTC time, and you get the time drift by comparing it with Internet time.

Hello @uugear

After 24h I have about 1s of delay so it seems that the RTC clock is not the problem afterall. I am still not sure why though. I will keep investigating.

In the meantimes I have found why I had 25-35s of delay between the RTC and System clock after boot (e.g after witty set up the system clock from the RTC clock)

in utilities.sh you have

rtc_to_system()
{
  log '  Writing RTC time to system...'
  local rtc_ts=$(get_rtc_timestamp)
  sudo timedatectl set-ntp 0 >/dev/null
  sudo date -s @$rtc_ts >/dev/null
  TIME_UNKNOWN=0
  log '  Done :-)'
}

but

sudo timedatectl set-ntp 0 >/dev/null

 takes 25-35s on my Rpi zero to be executed.

Since you are interrogating the "get_rtc_timestamp" before calling "timedatectl" and then after updating the system time, you loose that resolution

Inverting 

local rtc_ts=$(get_rtc_timestamp)
sudo timedatectl set-ntp 0 >/dev/null

works a lot better for me (and should be more accurate for all your customers)

This is the solved code:

rtc_to_system()
{
  log '  Writing RTC time to system...'
  sudo timedatectl set-ntp 0 >/dev/null
  local rtc_ts=$(get_rtc_timestamp)
  sudo date -s @$rtc_ts >/dev/null
  TIME_UNKNOWN=0
  log '  Done :-)'
}

@nolwenn

Posted by: @nolwenn

↑

but

sudo timedatectl set-ntp 0 >/dev/null

 takes 25-35s on my Rpi zero to be executed.

This is definitely not normal, that command should return in no time.

You may run this command to see which step is stuck:

sudo strace -r timedatectl set-ntp 0

Interesting. I will check that. Thanks