next_check and next_gps_update stored a future millis() value in a signed
long and compared with a naive '>'. After the ~24.8-day millis() sign flip
the deadline sits above the wrapped millis(), so the block never runs again
and GPS->RTC time-sync (and the location cache refresh) stall permanently
until reboot. Switch to unsigned deadlines with the wrap-safe signed-
difference compare '(long)(millis() - deadline) > 0', matching the idiom in
Dispatcher::millisHasNowPassed.
Also: reorder the MicroNMEALocationProvider ctor init-list to declaration
order (silences -Wreorder) and drop the always-true 'if (_claims > 0)' guard
in claim() (claim() always runs after _claims++, so it is >= 1).
Unless your GPS is being spoofed there isn't really a downside to
syncing more often with GPS.
I understand the RTC is very stable, but especially with powersaving now
clock drift is worse, we should sync more often.
On the T114, GPS_RESET (pin 38) is the same pin as PIN_3V3_EN.
MicroNMEALocationProvider::begin() sets pin 38 HIGH (powering the 3V3
rail) but stop() never set it back LOW, leaving the GPS module powered
even when disabled.
Assert reset pin in stop() to mirror begin(), and guard
_location->loop() behind gps_active check.
Fixesmeshcore-dev/MeshCore#1628
Jody Bentley
Liam CottleandGitHub
Quency-D
Wessel NieboerandWessel Nieboer
ripplebizandGitHub
Florent
Scott Powell
JQ