Proper unsigned value support for CRSF Telemetry

[CapnBry]

Alters the deserialization of CRSF telemetry to properly support unsigned values, and removes the check for values being -1.

Details

The CRSF telemetry parser currently unpacks every value as signed, regardless of what the spec says for that parameter. There are unsigned values in the spec though, and the current code (going all the way back) does not present them properly. For example the GPS packet's heading value is unsigned and that means that any value greater than 327.67 degrees shows up as negative. Betaflight telemetry example:

In addition, the current code checks for values where every byte sent is 0xff and discards the value if that condition is met. There is nothing in the CRSF spec that says "send 0xff... to not update the value", the only mention is on the 0x09 Barometric Altitude description where the example contains a comment stating "OpenTX counts any 0xFFFF [altitude] value as incorrect". Due to this code being used always, any telemetry parameter anywhere will ignore 0xff, 0xffff, 0xffffff, or 0xffffffff. This has been removed for also not matching the CRSF spec.

I also removed the template function used to do the parsing. I am not sure who was like ooh this is gonna really optimize performance when the compiler unrolls that loop for me! It's stupid, just pass the size.

Now-Unsigned Telemetry Items

• GPS - Ground Speed, Heading, Altitude (uses -1000 offset), satellites
• Baro Alt - Altitude (encoded)
• Airspeed
• RPM - Sensor ID
• Temp - Sensor ID
• Cells/Voltages - Sensor ID, Voltage (in both types)
• Link RX - RSSI percentage, RF Power dBm
• Link TX - RSSI percentage, RF Power dBm, FPS
• Battery - "Capacity" (mAh consumed), Percent remaining
• CRSFShot / OpenTX Sync - Update Interval

See? It works! Code size is also reduced by this change by 192 bytes.

[3djc]

To be fair, initial CRSF support was done with minimal documentation.

[pfeerick]

Wasn’t the initial support done by or in collaboration with TBS though? I thought that was the reason OpenTX and Betaflight implementations of CRSF was considered the defence implementation by many. Not taking into account the changes to the CRSF spec over time, or bugs in the initial implementation.  On a personal note, it will be nice to have non-negative headings... 😂