Repository navigation
rak4631: forward the first-fix limit and gps diag to the serial GPS - #3844
Merged
Merged
Conversation
RakLocationProvider wraps a MicroNMEALocationProvider but did not override setFirstFixTimeout(), getFirstFixTimeout() or formatDiagnostics(), so on RAK4631 boards with a serial GPS: - `gps firstfix` always answered "0 (no limit)" (the LocationProvider default), while the limit in force was the build default (1 h); - `gps firstfix <n>` saved the value but never applied it, at once or at boot; - `gps diag` gave the short base form, without the UART/NMEA counters or fm:. Forward all three to the NMEA provider. The RAK12500 (I2C) path has no first-fix limit, so it keeps reporting 0 and the short diagnostics. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collaborator
|
thanks to following what happens on Rak, as I don't have rak gps (and no available boards to test (other than rak3272 of course ;)) |
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.
RakLocationProviderwraps aMicroNMEALocationProviderbut doesn't overridesetFirstFixTimeout(),getFirstFixTimeout()orformatDiagnostics()(added in #3823 and #3821). So on a RAK4631 with a serial GPS:gps firstfixalways answers> 0 (no limit), but the limit in force is the build default (1 h);gps firstfix <n>saves the value but never applies it, either at once or at boot;gps diaggives the short base form (en: sat: fix:), without the UART/NMEA counters orfm:.This forwards all three to the NMEA provider. The RAK12500 (I2C) path has no first-fix limit, so it still reports 0
and the short diagnostics.
Tested
RAK WisMesh Repeater Mini v2 (RAK4631, RAK19007, RAK12501 serial L76K),
RAK_4631_repeater_gps_power.On
7f7512d9today:gps firstfix→> 0 (no limit),gps diag→> req:1 en:0 sat:6 fix:0.With this PR, flashed by OTA:
gps firstfix→> 3600;gps firstfix 30m, thengps firstfix→> 1800; afterrebootstill> 1800(applied at boot);gps firstfix 1h→OK.gps diagafter the boot fix, GPS off again:> req:1 en:0 ub:9376 ua:39970 ok:188 bad:1 na:39970 sat:6 fix:0 fa:39970 bc:3 sc:1 fm:0.RAK_4631_repeater,RAK_4631_repeater_gps_powerandRAK_4631_companion_radio_blebuild. Not tested on a RAK12500.Who did what: I worked on this with Claude Code. I found the replies on my repeater and flashed the builds. Claude
traced the cause, wrote the patch, and drafted this text, which I reviewed before posting.
🤖 Generated with Claude Code