Repository navigation
gps: don't let the settle time close a periodic window before the time sync - #3845
Merged
Merged
Conversation
…e sync In periodic mode a window closed after GPS_FIX_SETTLE_MS (10 s) from the first fix even if the clock sync was still pending. The sync needs about 4 s of continuous valid fixes (time_valid > 2, reset on any pass without a fix), so after a hot start, when the receiver reports a fix within seconds but not yet steadily, the window could close unsynced. On a board without an RTC the clock then stays at its default until the next window, a whole period later. Close the window only once the sync has been tried (done, not needed, or refused by GPS_GUARD); the settle time and the satellite count apply after that. The acquisition timeout still bounds the window. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
|
looks good, Thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In periodic mode, a window closes after
GPS_FIX_SETTLE_MS(10 s) from the first fix even if the clock sync is stillpending. The sync needs about 4 s of continuous valid fixes (
time_valid > 2, reset on any pass without a fix). After ahot start the receiver can report a fix within seconds, before it's steady, and the window then closes unsynced. On a
board without an RTC the clock stays at its default (15 May 2024) until the next window, a whole period later.
Seen on a RAK4631 repeater with an L76K (RAK12501),
gps period 1d: arebootabout 30 min after a fix gavegps fix_statsttf:5s/5s ok:1 miss:0andclock11:03 - 15/5/2024 UTC10 min later.gps diagshowed thelast UART byte, sentence and fix at the same moment, with 6 satellites and 188 sentences in all, about 5 s plus the
10 s settle. Every earlier fix on that unit was a 27 to 35 s cold start and synced fine.
This closes the window only once the sync has been tried (done, not needed, or refused by
GPS_GUARD); the settle timeand the satellite count apply after that. The acquisition timeout (5 min once there's a fix) still bounds the window.
Tested
Same repeater, three hot starts within an hour of a fix (the OTA, then two
reboots),clockabout a minute aftereach boot (a boot resets it to 15 May 2024, so a right clock means the GPS set it):
ttfgps diagsentencesclockrebootreboot(Window from the
ok:count at about 12.5 sentences a second.) On the second one,gps diagabout 11 s in still hadthe GPS on with
fix:1 fm:3 sat:6, and the time took about 13 s after the first fix to settle, so without thischange that window would most likely have closed at the 10 s settle mark, unsynced.
RAK_4631_repeater_gps_power(also with-D GPS_GUARD),Heltec_t114_repeaterandRAK_4631_companion_radio_blebuild.Who did what: I worked on this with Claude Code. I found the wrong clock on my repeater and ran the commands. Claude
traced the cause, wrote the patch, and drafted this text, which I reviewed before posting.
🤖 Generated with Claude Code