Repository navigation
Limit the first periodic GPS acquisition after boot - #3823
Conversation
Before the first fix since boot, a periodic acquisition had no timeout. If no fix is accepted (no sky view, no antenna, or a guard rejecting spoofed fixes), the receiver then stayed on until a fix was accepted. Give that window its own limit, GPS_FIRST_FIX_TIMEOUT_MS (15 min by default, enough for a full almanac; 0 keeps the old behaviour). It counts as a miss and the next acquisition starts after the configured period.
|
@fdlamotte gentle ping on this one too. Without it, a node that never gets a valid fix after boot (no sky view, or every fix rejected by |
|
At first I was doing that, but where I am nodes take sometimes 30min to get a fix (even outside) then as the almanach is downloaded the fix are shorter ... so I set up this policy Could make it something like an hour It's also a different problem for repeaters and companions maybe it would be good to have a preference for that (instead of a compile time option) ? |
A cold start can take up to ~30 min with a weak sky view, so the default limit before the first fix since boot goes from 15 min to 1 h. The limit is now a GPS preference, set with `gps firstfix <duration>` (0 = no limit, at most 1 day) and saved with the other GPS settings, so repeaters and companions can use different values without a rebuild. GPS_FIRST_FIX_TIMEOUT_MS stays as the build default.
|
Agreed, thanks. Updated:
Tested on our Faketec board: get/set, persistence across reboot, and a 5 s limit after reboot (GPS off, |
|
looks good to me, nice job |
Before the first fix since boot, a periodic acquisition has no timeout ("cold start can be long"). If no fix is ever accepted — no sky view, a disconnected antenna, or
GPS_GUARDrejecting spoofed fixes — the receiver stays on until a fix is accepted. On a solar node that's tens of mA for as long as the condition lasts, and the fix-stats never report a miss.This gives that window its own limit: 1 h by default (
GPS_FIRST_FIX_TIMEOUT_MS), changed at runtime withgps firstfix <duration>(0= no limit, at most1d) and saved with the other GPS settings. When it expires, the window counts as a miss and the next acquisition starts after the configured period. Windows after the first fix still useGPS_PERIODIC_ACQUISITION_TIMEOUT_MS(5 min).Tested on a Faketec (nRF52840, u-blox MAX-M10S,
GPS_GUARD), built withGPS_FIRST_FIX_TIMEOUT_MS=60000and a 2 min period:gps fix_stats→miss:1; next window the same (miss:2)rej region): every window stopped at the limit,miss:3…miss:9over ~25 minttf:7s ok:1 miss:0Also builds for
RAK_4631_repeater, with and withoutGPS_GUARD/GPS_FIRST_FIX_TIMEOUT_MS=0.gps firstfix(second commit), same board: get/set, persistence across reboot, invalid values rejected (abc,2d), andgps firstfix 5s+ reboot: GPS off after 5 s without a fix,miss:1. Also builds forHeltec_v3_companion_radio_ble.