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.

In the proposal PR here, the 11-bit proportional channels 17 to 32 are transported in a dedicated 0x26 frame. This results that the frame rate of the channels 17 to 32 could easily differ from the std. 0x16 RC Channels Packed Payload (channels 1 to 16) 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
:)

[RadioMasterRC]

Hi all, Just wanted to add us to the list of interested parties, we have received requests for 32-channel support also.

Thanks!

[CapnBry]

I would love to see an upgrade to the channel support in CRSF!

@rotorman I'm not a huge fan of this extension. The CRSF 11 bit channel data format is not great, as it takes data from EdgeTX which has a larger range and higher precision then dumbs it down to the same fixed, non-extensible format of the existing channels packed message. CRSF doesn't even use the full 11 bits of the 11 bits per channel in the CHANNELS_PACKED message.

I would much rather see is an upgrade to the SUBSET_PACKED definition, or I guess rather a new channels packet entirely since this no longer is a "subset". Ideally the protocol would take the full precision, full range that exists in EdgeTX. A CRSF packet can hold 32x 13 bit values, so there's no reason to "subset" anything, other than to set the format of a section of channels.

• format: 8 bits
  • 0 = 4ch 12 bit 988-2012 (6 bytes)
  • 1 = 4ch 12 bit 467-2524 (6 bytes)
  • 2 = 8ch 13 bit 988-2012 (13 bytes)
  • 3 = 8ch 1 bit either 988/2012 (1 byte)
  • 4 = 4ch 8 bit 988-2012 (4 bytes)
  • 5 = 8ch 11 bit 988-2012 (11 bytes)
  • 6 = 8ch 11 bit 467-2524 (11 bytes)
  • 7-255 reserved for future use

The structure repeats as many times as you need and fits in a CRSF packet, so you could have something as weird as this

• 4ch 12 bit 467-2524 (ch1-4)
• 8ch 11 bit 467-2524 (ch5-12)
• 8ch 1 bit 988/2012 (ch13-20)
• 8ch 11 bit 467-2524 (ch21-28)
• 4ch 12 bit 988-2012 (ch29-32)

There's not a ton of usefulness added here, but can cut down on transfer time? In the EdgeTX case, they can just send the number of channels the user has configured, in 4ch 12 bit blocks that use the proper format code if the user has extended limits on or not. e.g. for a user with up to 8 channels configured in the handset there would be 2x 4ch blocks, or 3+1+6+1+6+1=18 bytes. 24 channels would just be 6x 4ch blocks. The existing 11 bit 16ch would be 2x 8ch 11 bit blocks, just 2 bytes longer than the existing channels_packed for the 2 format specifiers, but would either support a wider range of values or a higher precision depending on the format.

The formats are up for debate, but I do not see the point in adding a second channels packet with the exact same format and interleaving it with other channels packets, when there's plenty of room in a CRSF packet for all the channels at once at full rate even at 13 bit precision that nobody does currently, right? I understand the desire for backward compatibility, the proposal would allow older devices to still get those first 16 channels, but if you're adding a new packet type FOR THE LOVE OF ALL THAT IS HOLY do not make it CRSF channel encoding that still only covers 880-2120us and only has 10.6 bits of precision in the 1000-2000 range. 🤣 Everything could be better, not just more channels!

[wimalopaan]

I really like this idea of a flexible rc-channels packet format: the possibility the pack e.g. 32 low-resolution and some 1-bit channels together is of special interest to function/ship-modelists. So, I really support this idea!

[rotorman]

Indeed my suggestion in this PR was explicitly targeting for maximum compatibility with existing systems.

If we are talking about devising a brand new CRSF frame, then I would suggest to go directly with 16-bit/channel (int16) and let the RF module discard the (least significant) bits it is not transmitting in the chosen OTA protocol.
Thus, the payload could be something like:

• number of channels transmitted
• int16 value(s) of the channel(s), where 0 is center and -32768 one extreme and +32767 the other.

How the int16 value is converted to the PWM output (and even if it is converted at all, consider e.g. DroneCAN), is then up to the receiver (configuration) to decide. Also various manufacturers can implement differing "servo" centers (e.g. some proprietary systems use 1520µs, whereas most open-source systems use 1500µs).

[olliw42]

• 32 x 16 bits would not fit
• I would also go with one CRSF for all 32 values
• I would most strongly advice against NOT specifying the meaning of the bits
• if going with one CRSF for all 32 values, I would also suggest 13 bits per channel, and as regards the meaning of that value I would strongly recommend the MAVLink formula (it can even be implemented on 16 bit mcus) https://mavlink.io/en/messages/development.html#RADIO_RC_CHANNELS
• I would not do any format nonsense, since if it fits it fits
• I think one byte (or unit16) for flag bits should be added. The message could/should be used also on the receiver-FC side, and the receiver may commuinicate additional info to the fc

[wimalopaan]

If anyone is interested: I modified ELRSV4 (master) to transport 32 rc channels.

You can find the modification here:

https://github.com/wimalopaan/ExpressLRS/tree/wmextensions

You have to use that version both on TX as well as on RX because the OTA format was modified and there were no more free bits (well, at first) to make that run-time selectable.

You'll also this EdgeTX mod:

https://github.com/wimalopaan/edgetx/tree/wmcrsfchanext

This mod is based on @rotorman 's work, but adds the ability to detect the modified ELRS. Without this EdgeTx mod the ELRS TX is flooded with packages.

P.S. be aware that this ELRS mod contains as well other modfications like the SumDV3, MultiSwitch and RGBLed support. The 32 channels support can be switched on/off at compiletime.

[wimalopaan]

Since ELRS already uses a flexible 0x16 format, we could also extend to definition of the 0x16 packet

1. only 16 channels
2. 16 channels + one byte (elrsv4 arming and future status)
3. 32 channel + one byte (s.a.)

This wouldn't require a new packet type (and should be compatible or could be easily made compatible)