fix(sport): add Betaflight Pitch/Roll sensor unit and precision (#7116)

[bultodepapas]

Fixes #7116

Summary

Betaflight S.Port telemetry sends Pitch (0x5230) and Roll (0x5240) sensors with the value encoded as degrees * 10. These IDs fall in the DIY range (0x5100-0x52FF) and were discovered without any unit or precision, so the radio displayed - as unit and 0.- as precision.

Fix

Added the two Betaflight angle sensors to the sportSensors table in frsky_sport.cpp:

• 0x5230 → Pitch, UNIT_DEGREE, precision 1 (value / 10)
• 0x5240 → Roll, UNIT_DEGREE, precision 1 (value / 10)

So a raw value of 532 is now displayed as 53.2 degrees.

Tests

Added FrSkySPORT.BetaflightAngleSensors in radio/src/tests/frsky.cpp verifying that:

• a S.Port frame with dataId 0x5230 discovers a sensor with UNIT_DEGREE / precision 1 and stores the raw value
• a S.Port frame with dataId 0x5240 discovers the Roll sensor likewise (including negative values)

[Copilot]

Pull request overview

Adds explicit metadata for Betaflight S.Port DIY Pitch/Roll sensors so they display with degrees and one decimal place, and introduces a unit test to validate discovery and value handling.

Changes:

• Register S.Port data IDs 0x5230 (Pitch) and 0x5240 (Roll) in the FrSky S.Port sensor table with UNIT_DEGREE and precision 1.
• Add a test that feeds synthetic S.Port frames for these IDs and asserts correct unit/precision and raw value storage.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
radio/src/telemetry/frsky_sport.cpp	Adds Pitch/Roll DIY sensor definitions with degree unit and 0.1 precision.
radio/src/tests/frsky.cpp	Adds a test covering Betaflight Pitch/Roll sensor discovery and signed values.

Suppressed comments (1)

radio/src/tests/frsky.cpp:544

• Same as above: the uint16_t* / int32_t* casts here can cause unaligned writes and strict-aliasing UB, and depend on host endianness. Writing the packet bytes explicitly avoids platform-dependent failures.

  packet[0] = 0x52;
  packet[1] = 0x10;
  *((uint16_t *)(packet+2)) = 0x5240;  // Roll
  *((int32_t *)(packet+4)) = -124;     // -12.4 deg

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[3djc]

Several issues with this:

• don't hardcode sensor id, add them to the table in corresponding .h file.
• 0x5100 to 0x52FF is dedicated to DIY, that is free for anyone to use as they which. You are fixing 2 values in that range that others might be using for other purposes
• shouldn't the fix be for Betaflight to use existing ACCX and ACCY sensor id, making sure they don't break someone else implementation ?

[bultodepapas]

Thanks for calling this out. I agree that moving the constants into the header would address only the organization issue, not the more important semantic one.

Because 0x5100-0x52FF is a user-defined range, EdgeTX cannot safely assign universal Pitch/Roll meaning to 0x5230 and 0x5240 without risking collisions with other implementations. The cleaner fix is for Betaflight to emit the existing ACCX / ACCY sensor IDs. I will investigate that direction rather than adding header constants or changing the EdgeTX sensor table unless you recommend a collision-safe compatibility mechanism for existing Betaflight versions.

I also rechecked my earlier test fix: explicit ID bytes removed the unaligned/aliasing issue, but memcpy for the value still depends on host byte order. If this EdgeTX PR continues, I will replace that with explicit little-endian value serialization as well.

For now I will leave the implementation unchanged while we agree on which project should own the fix.