Skip to content

fix(crsf): fall back to GPS altitude while no baro frame has been decoded - #31

Open
b14ckyy wants to merge 1 commit into
masterfrom
fix/crsf-baro-altitude
Open

fix(crsf): fall back to GPS altitude while no baro frame has been decoded#31
b14ckyy wants to merge 1 commit into
masterfrom
fix/crsf-baro-altitude

Conversation

@b14ckyy

@b14ckyy b14ckyy commented Aug 4, 2026

Copy link
Copy Markdown
Owner

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_alt is only filled
by the 0x09 frame. INAV sends that frame only since 9.0 (commit 67fb0859, first shipped
2026-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 in alt_m → flat 3D
tracks.

Fix. A seen_baro flag flips the moment a 0x09 frame is actually decoded — presence, not
value. 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_m holds real stored zeros).
No migration effort pre-release; the fix applies to new recordings.

Checks: cargo check + cargo test --no-run clean. 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.

…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
b14ckyy force-pushed the fix/crsf-baro-altitude branch from 82004ea to 903c887 Compare August 4, 2026 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] CRSF recordings show 0 altitude when read back from DB

1 participant