fix(crsf): fall back to GPS altitude while no baro frame has been decoded - #31
Open
b14ckyy wants to merge 1 commit into
Open
fix(crsf): fall back to GPS altitude while no baro frame has been decoded#31b14ckyy wants to merge 1 commit into
b14ckyy wants to merge 1 commit into
Conversation
…oded The CRSF decoder published the altitude event as a hard 0.0 whenever VARIO frames arrived without BARO_ALTITUDE (0x09): the vario sets the fresh-altitude flag on its own, and `baro_alt` is only ever filled by the 0x09 frame. INAV sends that frame only since 9.0 (with a detected baro), so on INAV 8.x the ALT widget sat at 0.0 live and every recording stored a real zero into baro_alt_m — which replay then rightly preferred over the good GPS altitude sitting in alt_m. Flat 3D tracks, issue #30. Confirmed on the reporter's INAV 8.0.1 + ELRS 3.5.x. The fallback keys on presence, not value: a `seen_baro` flag flips the moment a 0x09 frame is actually decoded. A genuine baro reading of 0.0 stays 0.0, and a link that does send the frame (Crossfire, mLRS, ELRS with INAV 9) never enters the fallback branch — behaviour there is bit-identical to before. Both CRSF altitudes share the arming-relative reference for INAV, so consumers see no semantic change either way. Fixes #30 Co-Authored-By: Claude Opus 4.8
b14ckyy
force-pushed
the
fix/crsf-baro-altitude
branch
from
August 4, 2026 09:30
82004ea to
903c887
Compare
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.
Fixes #30.
Root cause. The CRSF decoder published the altitude event as a hard 0.0 whenever VARIO frames
arrived without BARO_ALTITUDE (0x09) — vario alone triggers the event, and
baro_altis only filledby the 0x09 frame. INAV sends that frame only since 9.0 (commit
67fb0859, first shipped2026-01-17) and gates it on a detected baro; VARIO goes out far earlier (baro or fixed-wing + GPS).
Confirmed on the reporter's setup: INAV 8.0.1 + ELRS 3.5.x — the FC never emits the frame, the
link is innocent. So the ALT widget sat at 0.0 live, and every recording stored a genuine zero into
baro_alt_m, which replay then rightly preferred over the good GPS altitude inalt_m→ flat 3Dtracks.
Fix. A
seen_baroflag flips the moment a 0x09 frame is actually decoded — presence, notvalue. Until then the altitude event carries the GPS frame's altitude, which INAV fills
arming-relative (verified against a real INAV 9.1 recording: both CRSF altitudes share the same
reference), so the existing ground-anchor machinery applies unchanged. A genuine baro reading of 0.0
stays 0.0, and any link that does send 0x09 (Crossfire, mLRS, ELRS + INAV 9) never enters the
fallback branch — behaviour there is bit-identical to before.
Deliberately not done: rescuing existing recordings (their
baro_alt_mholds real stored zeros).No migration effort pre-release; the fix applies to new recordings.
Checks:
cargo check+cargo test --no-runclean. Frontend untouched.Verification plan: release build from this branch goes to the reporter; merge on their
confirmation that the ALT widget and new recordings show altitude on INAV 8.x.