feat: Adds frame type 0x26 RC Extended Channels Packed Payload

[rotorman]

EdgeTX supports internally 32 channels across all radio types:

• color screen targets: https://github.com/EdgeTX/edgetx/blob/a1cf7564a572ac24ea1ca11504729c0c2b19378b/radio/src/dataconstants.h#L45
• black-and-white screen targets https://github.com/EdgeTX/edgetx/blob/a1cf7564a572ac24ea1ca11504729c0c2b19378b/radio/src/dataconstants.h#L74 and https://github.com/EdgeTX/edgetx/blob/a1cf7564a572ac24ea1ca11504729c0c2b19378b/radio/src/dataconstants.h#L60

This PR extends the CRSF protocol specification to transport (optionally) up to 32 proportional 11-bit wide channels in order for the CRSF protocol not to be a limiting factor.

As the 11-bit proportional channels 17 to 32 are transported in a dedicated 0x26 frame, it's frame rate could easily differ from the std. 0x16 RC Channels Packed Payload framerate.

Tested successfully with rotorman/CyberBrick_ESPNOW#8 paired with EdgeTX/edgetx#6504.

[wimalopaan]

This would be very valuable to all the function-/ship-modelists. There is an even growing community that uses CRSF-based RF-links. These people are eagerly looking for solutions transporting 32 rc-channels.

As a side not: they do not only need more than 16 rc-channels, they also need up to 64 (or more) binary switch states to be transported over the rf-link (this is a clear benefit of the rc-systems that use e.g. SumDV3 protocol like Gr/SJ Hott). So, it would be also very helpful to add a package type for that purpose.

The channel data and the switch data may be transported in OTA packages with different update rates (like Hott does).

[olliw42]

fantastic to see efforts into this direction. Extending beyong 16 channels is certainly much desired for ground based vehicles.

however, I'm not convinced the proposed message is the right step forward, and I'm not convinced it even is needed. There is the message 0x17 Subset RC Channels Packed which is quite flexible and - as much as I can see - perfectly can do that. It is also already implemented in e.g. ArduPilot, so no additional mess also on this side.
The only issue is that it is put on hold (discouraged for implementation) ... no idea what the reasosn are here, but it looks to me that one "just " would have to make that official.

@tbs-trappy ?

[rotorman]

Here is the direct link to the 0x17 Subset RC Channels Packed frame, Olli is referring to: https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md#0x17-subset-rc-channels-packed
The "discouraged" flag is also the reason for me proposing the new 0x26 RC Extended Channels Packed Payload frame in this PR.
If there is no valid reason not to remove the discouraged flag, I am more than happy to close this PR and move forward with using 0x17. The 0x17 needs some further specifying parameters though, before it can be used in reality. E.g. the meaning of the digital_switch_flag bit and how many channels can maximally be transported in a frame, according to the resolution.

For the reference, here the (IMHO suboptimal) ArduPilot implementation of the CRSF 0x17 frame:
https://github.com/ArduPilot/ardupilot/blob/ceb5ad848a5c41820c2bf37b1908a7b54600a346/libraries/AP_RCProtocol/AP_RCProtocol_CRSF.cpp#L462-L466

https://github.com/ArduPilot/ardupilot/blob/ceb5ad848a5c41820c2bf37b1908a7b54600a346/libraries/AP_RCProtocol/AP_RCProtocol_CRSF.h#L246-L257
and
https://github.com/ArduPilot/ardupilot/blob/ceb5ad848a5c41820c2bf37b1908a7b54600a346/libraries/AP_RCProtocol/AP_RCProtocol_CRSF.cpp#L525-L589 (the latter crudely ignores the last function parameter and writes directly into global _channels 😬 )

In addition, note the incomplete handling of CRSF 0x17 frame by ArduPilot: https://github.com/ArduPilot/ardupilot/blob/ceb5ad848a5c41820c2bf37b1908a7b54600a346/libraries/AP_RCProtocol/AP_RCProtocol_CRSF.h#L253-L256

[b14ckyy]

That would be a great addition for INAV as well.

The change to support CRSF with 32CH could be easily done since INAV supports up to 32+2 channels total already for Futaba SBUS2.
With MSP-RC its also possible to control 32 channels since INAV 8 via mLRS but since the Radio to mLRS Communication is limited to 16CH at the moment, the other 16 can only be utilized by sideloading through a GCS Application.

There are a lot of applications that can require more than 16 available channels.

[wimalopaan]

The change to support CRSF with 32CH could be easily done since INAV supports up to 32+2 channels total already for Futaba SBUS2.

I don't want to disturb this discussion, but afaik the SBUS2 proto is a bidi extension of SBUS to query telemetry data, but sticks to 16 channels. Maybe I'm wrong here?

[wimalopaan]

E.g. the meaning of the digital_switch_flag bit

My understanding of that flag is, that it indicates the meaning of the following data: channel-values (with the specified resolution) or binary switches state (each bit resembles a binary switch).

[rotorman]

My point was that the specs should make it clear, without a shadow of a doubt, what each bit/byte does or is it for. Presently the usage of digital_switch_flag is vague and there is room for (various) interpretations, causing at the end issues, when implemented by various projects with differing interpretations of the meaning.

[wimalopaan]

My point was that the specs should make it clear, without a shadow of a doubt, what each bit/byte does or is it for.

Absolutely.
I just want to make visible, that there is a group of users that is eaderly waiting for such a feature in CRSF ;-)

[rotorman]

@tbs-trappy / @Dazza0 Can we have an executive decision please, either to rework/update 0x17 Subset RC Channels Packed https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md#0x17-subset-rc-channels-packed or to go further with this PR introducing a new 0x26 frame to cater proportional 11-bit channels 17 to 32.

[b14ckyy]

The change to support CRSF with 32CH could be easily done since INAV supports up to 32+2 channels total already for Futaba SBUS2.

I don't want to disturb this discussion, but afaik the SBUS2 proto is a bidi extension of SBUS to query telemetry data, but sticks to 16 channels. Maybe I'm wrong here?

iNavFlight/inav#10270

[bkleiner]

Folks, pinging people over and over again will not make it go faster or make it more likely for anything to accepted, so I kindly ask to refrain from doing that.

0x17 Is discouraged because we are aware of ambiguities and because most of the additional functionality there was never implemented both on the producing and receiving side. However as the CRSF spec now expands far beyond TBS product line, I am of the opinion that changing it will only add to the mess.

Can we have an executive decision please, either to rework/update 0x17 Subset RC Channels Packed https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md#0x17-subset-rc-channels-packed or to go further with this PR introducing a new 0x26 frame to cater proportional 11-bit channels 17 to 32.

As much as I appreciate that you are actively trying to improve the situation here, I don’t think this is a „either or“ type of situation. Seems to me there is many more possible solutions to this problem and I also don’t see any reason to be rushing this, especially considering this Proposal has not even made it through the 2 weeks grace period we usually impose.

I will bring this PR to the attention of the team today and get back to you as soon as time permits.

TLDR: good shit, but daddy chill.

[olliw42]

first, many thanks for responding, much appreciated
we understand what you are saying, but I'm not sure that the pinging here is properly described as "over and over again"

0x17 Is discouraged because we are aware of ambiguities and because most of the additional functionality there was never implemented both on the producing and receiving side.

many thanks for the insight. I may not know all these ambiguities but it seems to me it should be possible to fix them in a backwards compatible way.

The fact that the additional functionality was never implemenetd IMHO does not imply that it's a badly designed message. And, let's be fair, it may also have to do with that the specs wasn't official. We at mLRS have discussion of the >16 topic since long and I recall having suggested it as a natural way to go 2 years ago.

As regards the functionality itself, I think it's a good idea. For instance, the native resolution of EdgeTx is 12 bits (if I'm not wrong), so it would make perfect sense to send with that resolution from radio to tx module. The link could then do what it wants, inlcuding using that full 12 bit or not, and send it out on the receiver as it wants. Why always the restriction to 11 bits. Mavlink can handle 13 bits.

I also don’t see any reason to be rushing this

point is that I see this dicussion for long floating through the different places, and if "no reason to rush" means to give it a good thought then I guess we are all with you but if it means not so important then I guess we would want to disagree.

[bkleiner]

first, many thanks for responding, much appreciated we understand what you are saying, but I'm not sure that the pinging here is properly described as "over and over again"

i think that is for the receiving end to judge :)

0x17 Is discouraged because we are aware of ambiguities and because most of the additional functionality there was never implemented both on the producing and receiving side.

many thanks for the insight. I may not know all these ambiguities but it seems to me it should be possible to fix them in a backwards compatible way.

The fact that the additional functionality was never implemenetd IMHO does not imply that it's a badly designed message. And, let's be fair, it may also have to do with that the specs wasn't official. We at mLRS have discussion of the >16 topic since long and I recall having suggested it as a natural way to go 2 years ago.

As regards the functionality itself, I think it's a good idea. For instance, the native resolution of EdgeTx is 12 bits (if I'm not wrong), so it would make perfect sense to send with that resolution from radio to tx module. The link could then do what it wants, inlcuding using that full 12 bit or not, and send it out on the receiver as it wants. Why always the restriction to 11 bits. Mavlink can handle 13 bits.

i don't necessarily disagree, but that will need much more careful consideration than a new frame and i wonder if that is "worth it" considering we could just as easily add a new frame that has similar functionality. i am purposely leaving that up discussion. i thought i made it more than clear that i meant to state my personal opinion on the matter.

I also don’t see any reason to be rushing this

point is that I see this dicussion for long floating through the different places, and if "no reason to rush" means to give it a good thought then I guess we are all with you but if it means not so important then I guess we would want to disagree.

that's just puzzling to me. yes, of course that means to say "good thought".

[olliw42]

@tbs-trappy
would be great if we could please see some consideration of this topic
:)