Goggle 2 real time clock does not keep time

[Growney]

Issue with the real time clock in the goggles not keeping time correctly.

Manifests in 2 ways:

1. Goggles time is out of sync after being off for an amount of time. So far from my testing it seems to end up fast compared to actual time. Which is strange considering the second issue.
2. When you set the time if you watch it tick past on the screen and time it it is roughly two seconds slow for every 30 seconds past vs timing on a stopwatch.

[lesharodin]

Noticed it too, RTC works really bad on g2, on g1 it was okay

[Sankie005]

Trying to fix this issue!

I would appreciate it if anyone suffering from the drift could hand me the following info so i can replicate it and find a solution!

1. RTC battery voltage, i can help anyone willing to take apart their Goggles 2 to probe the RTC battery with a multimeter to figure out it's voltage.
2. Timedatectl or similar info (i can send you the exact commands!)
3. Startup behavior with both an SD card in and out with something timestamping the video!

[lesharodin]

@Sankie005 there is no timedatectl in TinaLinux on googles

[lesharodin]

@Sankie005 my RTC battery is 2,9v

[Sankie005]

Progress news!

I think i've figured out a solution using hwclock! However i still need to find the exact offset, would appreciate the community's help in this!
first run these commands to make sure your clock is working:

ls -l /dev/rtc*
/bin/busybox hwclock -r

You should see something like the following output

root@tina:~# ls -l /dev/rtc*
lrwxrwxrwx    1 root     root             4 Nov 24  2025 /dev/rtc -> rtc0
crw-------    1 root     root      252,   0 Nov 24  2025 /dev/rtc0
root@tina:~# /bin/busybox hwclock -r
Mon Nov 24 01:08:38 2025  0.000000 seconds

Then manually update the clock using date utility
Set System Clock to Accurate Time (e.g., Nov 24, 2025, 09:15:00 PST):
date 1124091525

Then save it to your rtc with
/bin/busybox hwclock -w -u

Finally and this is hopefully the real fix!

Creating an etc/adjtime: This is simply a file that contains the drift value which is offset by the system on boot!

# Line 1: Zero drift rate (0.000000), 0 last adjustment time, 0 status
echo '0.000000 0 0' > /etc/adjtime

# Line 2: 0 last calibration time
echo '0' >> /etc/adjtime

# Line 3: Time scale is UTC
echo 'UTC' >> /etc/adjtime 

I'm out of time today but i will figure out the actual drift rate soon and it should then be able to correct itself! You can figure out the drift rate on your unit with the following formula:
Total Drift/Time period=drift rate
And since the clock seems to be ticking faster we will make the drift rate negative!
Untested fix as i haven't found the correct drift rate but i'll update you if it fixes it!

[Sankie005]

echo '-8640.000000 0 0' > /etc/adjtime
Thanks to @alfskaar on the discord for providing me with the values, Basically the clock is 10% faster and this should slow it down to be correct, from what i can tell there is the final question of where the file should go, i'm not familiar with what compilation options were used but if this fix doesn't work then the adjtime file may not be in the right position, either way i've applied this to my own goggles and will see if it makes a difference in a day!

[Sankie005]

Okay it's been a while and my clock is within the minute! Looks like this fixed it! Helped another community member set it up, let's see if it worked for them, in the meanwhile i can work on making this a part of the clock page UI, can anyone help me with the devcontainer.json for this project as the popup doesn't seem to show for me!

[lesharodin]

So I can just use
echo '-8640.000000 0 0' > /etc/adjtime
in goggles ssh to test it?

[Sankie005]

Yupp! That should do it! Would reccomend restarting right away so it gets loaded! Alternatively run the command below! After the echo commands

# Writes the system time to the RTC as UTC
/bin/busybox hwclock -w -u