Feature request: Receive headtracker signal (CRSF/S.Bus/PPM) and forward to Backpack

[black-funny-cat]

Feature Request

Overview:
Allow the ExpressLRS TX Backpack to receive headtracker signals using supported RC protocols (CRSF, S.Bus, or PPM) from an external headtracker device, decode the channel data, and forward yaw, pitch, and roll values to the Backpack via the MSP protocol.

Background:
Some headtracker devices output pan/tilt/roll data as CRSF, S.Bus, or PPM. Currently, there is no direct way to receive these signals on the TX Backpack and transparently forward them to the ExpressLRS module for use in goggles, antennas, or other accessories.

Proposed Implementation:

1. Add support (in firmware) to select and configure one serial port (or GPIO for PPM) to act as a receiver for one of the following protocols from an external headtracker device:
   • CRSF (preferred; native support and 16-ch digital)
   • S.Bus (standard FPV protocol)
   • PPM (legacy, rarely used now)
2. Parse the incoming signal and extract the channels associated with yaw, pitch, and roll (user should be able to select or configure mappings, or use sensible defaults like channels 5/6/7 for CRSF).
3. Reformat the channel data as an MSP packet (MSP_ELRS_BACKPACK_SET_PTR, opcode 0x0383), encoding yaw, pitch, and roll each as int16 and forwarding it on the main serial line to the ELRS module.
4. Document which hardware pins/UARTs should be used, and in which configuration (including notes about required baud rates, signal levels).

Benefits:

• Allow use of third-party headtrackers with native CRSF/S.Bus/PPM outputs to control ExpressLRS Backpack features such as antenna or goggle orientation.
• Flexible headtracking solution for a wide range of FPV setups without custom integration on the headtracker itself.

Optional/Extensions:

• Allow user to select which protocol and UART to use (selectable via config or compile-time flag)
• Support protocol auto-detection if feasible
• Pass through additional headtracker channels or allow custom mapping beyond pan/tilt/roll
• Basic status indication (LED or MSP feedback) when signals are being received

Related code references:

• src/Tx_main.cpp MSP packet handling
• module_crsf.cpp CRSF protocol parsing example
• Implement signal receiver for S.Bus and PPM as new modules if desired

---

Would you accept a PR for this?
I'd be happy to develop and test this support, but would welcome advice from maintainers regarding code structure or integration points.