Repository navigation
fix(ui): report the receiver as it is now, not as it was at boot - #218
Merged
Merged
Conversation
With 16 satellites and a 24.9 Hz fix stream the dashboard still showed what was true at 2.8 seconds, and Race mode said "lap times pending GNSS" throughout. ready_snapshot read the health live and correctly. refresh_ready was the problem: it is reached from boot, a settings save and a track change, and from nowhere else. The receiver acquires its first fix after the boot sequence has already drawn the screen - I (2810) timing: runtime started, fixes now reach the engine <- drawn here I (2990) gnss: fix accepted (sats 16, ...) <- fix after - so the dashboard drew a receiver that was not yet working and never corrected itself. Storage and IMU readiness had the same fault and merely happened to be ready by then. Refreshed from the display cadence now, gated twice: only while the dashboard is the active screen, and only when a fingerprint of the drawn state has changed. An idle dashboard costs a struct comparison. The gating is not tidiness - a repaint costs about 40 ms against a 25 ms service period (#213), so an unconditional refresh at 20 Hz would have spent the device's most expensive operation on producing an identical screen, and made #213 worse. The Race note was the fixed string "RACE - lap times pending GNSS". Honest while nothing consumed fixes, and since the timing runtime was wired both wrong and the most alarming thing the screen could say while everything worked. It now distinguishes no circuit armed, waiting for a fix, and lap times live, and is re-derived whenever the fingerprint moves. logging_available and session_active were hardcoded to false in the same snapshot. Logging is available once there is somewhere to write, and whether a session is running is something the router already tracks. Verified on hardware: the dashboard reads LAP TIMING READY, which prints only when gnss_health is good and the track state is selected, so both are being read live rather than carried from boot. Closes #217 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Closes #217. Reported from the device: 16 satellites, 24.9 Hz, and the screen still read
RACE - lap times pending GNSS.Two causes
The dashboard never repainted its health.
ready_snapshot()readsgnss_pipeline_.health()live and correctly — butrefresh_ready()is reached from boot, a settings save and a track change, and nowhere else. The boot ordering makes the stale read certain:Storage and IMU readiness had the same fault and merely happened to be ready by then.
The Race note was a fixed string. Honest while nothing consumed fixes; since #18 wired the timing runtime it was both wrong and the most alarming thing the screen could say while everything worked.
The fix, and why it is gated
service_ready_dashboard()runs on the display cadence, but only while the dashboard is the active screen and only when a fingerprint of the drawn state has changed. An idle dashboard costs a struct comparison.That gating is not tidiness. A repaint costs ~40 ms against a 25 ms service period (#213), so refreshing unconditionally at 20 Hz would have spent the device's most expensive operation redrawing an identical screen — and made #213 measurably worse.
The Race note is derived from the same state, so
describe_mode()is re-run on the same trigger. Three cases now:no circuit armed for lap times,waiting for a fix,lap times live.logging_availableandsession_activewere hardcodedfalsein the same snapshot; both are now read.Verification
make check→CHECK_RC=0LAP TIMING READY, which prints only whengnss_health == goodandtrack_state == selected— so both are being read live rather than carried from boot🤖 Generated with Claude Code