Repository navigation
RAK4631 GPS Time Sync Issue 1.15 #2359
Description
Hi!
Few days ago I've added GPS module to one of my repeaters (RAK4631).
Firmware version: 1.15
Device sees GPS module but doesn't sync clock to GPS time
gps on
OK
gps
on, active, fix, 19 sats
gps sync
OKAfter issuing gps sync command device says OK but actual time doesn't change.
Activity
cwichura commentedon Apr 22, 2026
gps syncdoes not immediately update the clock. It just sets a flag that is only checked periodically in the NMEA processor loop. It also needs three consecutive good fix reads before it will update the clock from GPS as well. So give it a bit and then check the clock.nsa-hq commentedon Jun 5, 2026
That doesn't work for me. I have a RAK4631 with the GPS module and I just ran a test of the gps sync and it's still showing the boot-up clock time plus one hour now. Below is a reprint of the commands I entered and the replies I received.
I finally entered the 'clock sync' command and now the repeater is showing today's date (6/5/2026 UTC) and the correct time. So the clock doesn't appear to pull time from the gps at all, unless I'm missing something.
Any help or suggestions would be appreciated. Thanks!
ik1iyu commentedon Jun 16, 2026
Hi!
I have the same behavior on my Heltec T114 repeater since fw v1.15 and now v1.16.
GPS module running ok, but gps sync command has no effect.
Thank you.
LennertVA commentedon Jun 17, 2026
Same behaviour here. Heltec T114, currently 1.15. Active GPS with fix and 15+ sats. After 10+ hours the clock is still on 2024.
gps syncdoes not sync it.clock syncdoes.IoTThinks commentedon Jul 25, 2026
"gps sync" only sets a flag to push the GPS trying to get time sync.
It may take a while to get time sync.
Please note, you need to put the GPS module OUTDOOR or at least besides the windows in clear sky.
It works on my variant and it should work on your MeshCore 1.16 too.
If MeshCore 1.16 doesnt, try this and use CLI "powersaving on", then "gps on" then "gps" to see the last sync.
You may force synce "gps sync".
I have tested RAK4631 and RAK12501 (L76K).
https://github.com/IoTThinks/EasySkyMesh/releases/tag/PowerSaving16.1
rinodods commentedon Aug 10, 2026
On RAK WisBlock boards (RAK 4631, RAK 4631, etc.) with a RAK12500 I2C GPS module, gps sync returns OK but the system clock never updates from the boot default (May 2024). GPS position data works correctly.
Root Cause
EnvironmentSensorManager::gpsIsAwake() detects the RAK12500 via I2C and swaps _location from MicroNMEALocationProvider to RAK12500LocationProvider. The NMEA provider has full clock sync logic, but the RAK12500 provider had none — it read GPS epoch data but never wrote it to the RTC clock. Additionally, the RTC clock reference was stored only in the NMEA provider and lost during the swap.
The RAK12500's ublox_GNSS.getUnixEpoch(2) can also return garbage values before GPS time is fully initialized, even though getGnssFixOk(8) (position fix) returns true. Position lock happens faster than time sync on the u-blox, so raw epoch values must be validated before use.
This affects all RAK boards using the RAK12500 I2C GPS (tracked in issues #2359 and #2786).
Changes
LocationProvider.h: Moved _clock from individual providers to the base class with setClock()/getClock() accessors. This allows the clock reference to survive provider swaps.
MicroNMEALocationProvider.h: Removed its own _clock member; now uses the inherited base class _clock via setClock().
EnvironmentSensorManager.cpp:
github-actions commentedon Nov 2, 2026
This issue is stale because it has been open for 60 days with no activity. Remove the stale label or add a comment if this issue is still relevant, otherwise this issue will automatically close in 7 days.
bcdouglas commentedon Nov 14, 2026
Ping. Someone with the know-how, please fix.
recrof commentedon Nov 14, 2026
@fdlamotte does your refactor touch this issue?
fdlamotte commentedon Nov 14, 2026
I've had no feedback from people using rak12500 (I don't (can't)) even know if gps still works on those devices while doing the refactor ... (I've asked for tester through github PR and in discord)
The old path has not been changed, and I've just verified, there is nothing in RakLocationProvider that deals with time sync (it will work for nmea version because all the calls are forwarded to NMEALocationProvider)
If we are testers here. First please report if GPS works with latest changes ... then I'll propose an implementation for time syncing
fdlamotte commentedon Nov 14, 2026
there is also a gps guard provided by @AlexandrTyshchenko that is not applied to Rak I2C gps ... but as the rak12500 is EOL, I would rather provide minimal support ... time sync is needed though
fdlamotte commentedon Nov 14, 2026
Well ... it should be as simple as #3843
Please someone with a rak board and I2C gps, test this and report if it work ...
It would both confirm that GPS refactor didn't break those gps and that the sync is ok
edit: adding a repeater firmware for 4631 built against dev+PR
firmware.zip