CRSF Baro Altitude and Vario, AirSpeed

[r1000ru]

User description

The previous merge request unfortunately had to be closed. Attempting to merge it with the main branch resulted in a huge number of conflicts.

This implementation has been tested and has the crsf_use_legacy_baro_packet setting disabled by default.

If this setting is disabled:

• The GNSS packet (0x02) contains ASL altitude.
• The VARIO packet (0x07) is not transmitted.
• The Barometric Altitude and Vertical Speed ​​packet (0x09) contains the altitude relative to the takeoff point and the vertical speed.

If this setting is enabled, data is transmitted in compatibility mode with current scripts:

• The GNSS packet contains the altitude relative to the takeoff point.
• The Barometric Altitude and Vertical Speed ​​packet is not transmitted.
• The VARIO packet contains the vertical speed.

The airspeed packet (0x0A) is transmitted in any case (if Pitot in use).

---

PR Type

Enhancement

---

Description

• Adds barometric altitude and vertical speed sensor packet (0x09)

• Implements airspeed sensor packet (0x0A) for Pitot tube support

• Introduces legacy mode toggle for backward compatibility

• Refactors GPS altitude handling based on configuration mode

---

Diagram Walkthrough

flowchart LR
  A["CRSF Telemetry"] --> B["Legacy Mode OFF"]
  A --> C["Legacy Mode ON"]
  B --> D["GPS: ASL Altitude"]
  B --> E["BaroVario: Altitude + Vario"]
  B --> F["Airspeed: Pitot Data"]
  C --> G["GPS: Relative Altitude"]
  C --> H["Vario: Vertical Speed"]

Loading

File Walkthrough

	Relevant files
Enhancement	crsf.h Define new CRSF frame types and payload sizes                        src/main/rx/crsf.h Added CRSF_FRAME_BAROMETER_ALTITUDE_VARIO_PAYLOAD_SIZE constant (3 bytes) Added CRSF_FRAME_AIRSPEED_PAYLOAD_SIZE constant (2 bytes) Renamed CRSF_FRAMETYPE_BAROMETER_ALTITUDE to CRSF_FRAMETYPE_BAROMETER_ALTITUDE_VARIO_SENSOR Added new frame type CRSF_FRAMETYPE_AIRSPEED_SENSOR (0x0A) +4/-1      crsf.c Implement barometric altitude/vario and airspeed telemetry src/main/telemetry/crsf.c Added #include for SCHAR_MIN and SCHAR_MAX constants Added #include "sensors/pitotmeter.h" for airspeed support Modified crsfFrameGps() to conditionally send ASL or relative altitude based on crsf_use_legacy_baro_packet setting Renamed crsfBarometerAltitude() to crsfFrameBarometerAltitudeVarioSensor() and added vertical speed calculation using logarithmic vario algorithm Added new crsfFrameAirSpeedSensor() function to transmit airspeed data Updated frame scheduling to use conditional logic for legacy vs. new barometric packet modes Added airspeed sensor scheduling when Pitot sensor is available +51/-20
Configuration changes	telemetry.c Add legacy barometric packet configuration option                src/main/telemetry/telemetry.c Incremented PG_TELEMETRY_CONFIG version from 8 to 9 Added crsf_use_legacy_baro_packet field initialization in reset template with default value +3/-2      telemetry.h Define legacy barometric packet configuration field            src/main/telemetry/telemetry.h Added bool crsf_use_legacy_baro_packet field to telemetryConfig_t structure +1/-0      settings.yaml Register CRSF legacy mode configuration setting                    src/main/fc/settings.yaml Added crsf_use_legacy_baro_packet configuration entry Set as boolean type with default value OFF Includes description of GPS altitude behavior in both modes +4/-0
Documentation	Settings.md Document CRSF legacy barometric packet setting                      docs/Settings.md Added documentation for crsf_use_legacy_baro_packet setting Explains behavior difference between legacy mode (ON) and new mode (OFF) Documents default value as OFF +10/-0

---

[qodo-merge-pro]

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix incorrect airspeed unit conversion Fix the airspeed calculation in crsfFrameAirSpeedSensor by correcting the conversion factor from cm/s to km/h. The current code results in a value 10 times too high. Also, update the comment to reflect the correct unit (km/h). src/main/telemetry/crsf.c [298-309] /* 0x0A Airspeed sensor Payload: -int16 Air speed ( dm/s ) +uint16_t Air speed ( km/h ) */ static void crsfFrameAirSpeedSensor(sbuf_t *dst) { // use sbufWrite since CRC does not include frame length sbufWriteU8(dst, CRSF_FRAME_AIRSPEED_PAYLOAD_SIZE + CRSF_FRAME_LENGTH_TYPE_CRC); crsfSerialize8(dst, CRSF_FRAMETYPE_AIRSPEED_SENSOR); - crsfSerialize16(dst, (uint16_t)(getAirspeedEstimate() * 36 / 100)); + crsfSerialize16(dst, (uint16_t)(getAirspeedEstimate() * 36 / 1000)); } Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a unit conversion bug in the new crsfFrameAirSpeedSensor function, where the calculated airspeed would be 10 times higher than the actual value. This is a critical fix for the new functionality.	High
	Prevent altitude calculation integer underflow Prevent a potential integer underflow in the altitude calculation for the CRSF GPS frame. Constrain the calculated altitude to a minimum of 0 before casting to uint16_t to avoid wrapping to a large positive value with negative altitudes. src/main/telemetry/crsf.c [218] -crsfSerialize16(dst, (uint16_t)( (telemetryConfig()->crsf_use_legacy_baro_packet ? getEstimatedActualPosition(Z) : gpsSol.llh.alt ) / 100 + 1000) ); +const int32_t altitude_cm = (telemetryConfig()->crsf_use_legacy_baro_packet ? getEstimatedActualPosition(Z) : gpsSol.llh.alt); +crsfSerialize16(dst, (uint16_t)constrain(altitude_cm / 100 + 1000, 0, UINT16_MAX)); Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a potential integer underflow when handling negative altitudes, which could lead to incorrect telemetry data. Applying a constraint is a robust way to prevent this bug.	Medium
Update

[MrD-RC]

Looking good. For the docs. Did you update it using the Python script?

[r1000ru]

Oops, i did it manualy. Fixed

[MrD-RC]

Can you resolve the conflicts please.

[r1000ru]

@MrD-RC I don't understand how I can resolve conflicts with a branch that isn't yet in master without creating a new branch and a new merge request for the merged version. Could you please merge pull request 11025 so I can change my pull request later?

[sensei-hacker]

@MrD-RC I don't understand how I can resolve conflicts with a branch that isn't yet in master without creating a new branch and a new merge request for the merged version. Could you please merge pull request 11025 so I can change my pull request later?

He may have been referring to conflicts you later fixed here:

f3eccbd

If Mr D can please confirm that's what you meant and this commit is good for RC1?

[MrD-RC]

Yes, there are no longer any conflicts.

Conflicts appear in the status box. They need to be resolved before merging.