Ability to set up single channel as bitfield for transmitting switched functions independently

[breadoven]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

There is always an issue with too many potential model functions but a lack of channels to control them all. Perhaps more of an issue today as controllers seem to have more and more switches available to use.

Describe the solution you'd like

It would be useful to have the ability to setup a channel as a bitfield assigned to various binary inputs, switches etc. Guessing this should allow around 10 switched inputs to be transmitted on a single channel which can be used by flight controller firmware as required.

Describe alternatives you've considered

Couldn't see any way of achieving this with the current functionality mainly because it's not possible to work in "us" values where required, it's generally all percentages which aren't accurate enough even if you could find a way of doing this via the current logic.

Additional context

No response

[3djc]

You can turn your radio into µS displayed by compiling with PPM_US option

[breadoven]

You can turn your radio into µS displayed by compiling with PPM_US option

Already did that. I couldn't see how that helped though, just displayed µs in the output screen, all other settings that could be used remain as percentage. Could be I'm missing some trick but I suspect the required logic isn't currently available in fact.

[breadoven]

I did manage to find a way to do this by using GVARS set to a precision of 0.0 which allows a mixer weight of 0.1 % resolution (1 µs). However, trying to set mixed values on a single channel that provides the required Bit field is pretty messy due to rounding issues and other limitations. Still I managed to get 9 Bits working. Just need to get it working with INAV now.

Would be a whole lot easier and more reliable though if a channel could be set up properly using bits directly rather than manipulating decimal values.

[raphaelcoeffic]

We should really do something to allow these uses-cases. That means however finding a way to avoid range conversions and/or any type of calculations in mixer + module driver, so that the values can be used as much as possible (as bitfield or anything you would like). This might require some specific functions that would allow passing channels directly to the module driver, thus by-passing everything else.

[gagarinlg]

Maybe set a channel, in the output page, as raw channel. Then the mixer does not touch the values, but just forwards them

[raphaelcoeffic]

Maybe set a channel, in the output page, as raw channel. Then the mixer does not touch the values, but just forwards them

Something along these lines.... Somebody should try to come up with an implementation.

[breadoven]

The issue I've found with this is the radio is seemingly outputting the correct channel values across 9 values but when received by INAV they are randomly out by 1µs on 2 or 3 values which renders it unusable. Don't know if this is a CRSF issue or an INAV issue ... some sort of integer rounding problem. Maybe this wouldn't happen if the Bits were set directly.

[3djc]

The issue is those modules and protocols where not designed initially to transmit digital data, they are not bit perfect, and every protocol is different in this regard, what may work for one might not for another.

Even for the same protocol, say ELRS, it will differ greatly depending of channel count and switch mode.

[breadoven]

Hmmm, it's irritating ... it almost works but not quite. But maybe that's why it's not been done already.

[breadoven]

Looking at the INAV code there's an obvious scope for error when it converts the raw CRSF RC channel date to PWM channel values:

/* conversion from RC value to PWM
 *       RC     PWM
 * min  172 ->  988us
 * mid  992 -> 1500us
 * max 1811 -> 2012us
 * scale factor = (2012-988) / (1811-172) = 0.62477120195241
 * offset = 988 - 172 * 0.62477120195241 = 880.53935326418548
 */
return (crsfChannelData[chan] * 1024 / 1639) + 881;

[breadoven]

After some more fiddling it seems the real issue is that with ELRS set with Aux channels in full resolution, with CRSF Extended Limits, it only outputs raw CRSF values between 172 and 1811 with a minimum increment of 2 which isn't accurate enough given it equates to around 1.25 us. You can only get an increment of 1 with the restricted resolution Aux channel modes which are obviously no use. So as far as ELRS is concerned this doesn't work.

[raphaelcoeffic]

@breadoven what this means is that you need to ensure digital transmission without any value range adaptations of any sort all the way from the radio to whatever is on the other side. By the way: I suppose the final use-case is to switch single outputs ON and OFF, right? You want want to use a different approach and make use of commands sent over the telemetry stream as is done for by the ELRS LUA script (or any other mechanism that allow to communicate with a remote MCU, like is done to setup some flight controller parameters or change video transmitter frequency).

[breadoven]

@raphaelcoeffic Someone asked why it wasn't possible to use a 10 bit RC signal as a bitfield to effectively provide 10 switched functions on a single channel. Sounded like it should be possible with digital control etc and would free up channels if it worked, so I thought I'd see what was possible. If such a method was possible it would make setting up modes much easier, no convoluted channel/switch mixes to set up and no mode function channel ranges to set up, instead you just enable a Bit field slot on a given Aux channel defined as a Bitfield channel and you have 10 independently controllable functions that can be assigned as required by the FC.

I'm wondering if ELRS could be configured to do this with a new channel mode, something similar to 16/2 but not using Extended Limits and with far fewer Aux channels (you wouldn't need many if 10 modes could be controlled by a single channel). Guess I'll ask the ELRS people if this is possible or a non starter.

I did also wonder if this might be possible using LUA scripts. Haven't checked into this and wouldn't know if it's even possible having little understanding of LUA.

[raphaelcoeffic]

@breadoven This is probably something that needs to discussed together with ELRS. It would be much easier if the output is not supposed to be some PPM, but digital as well (at best directly CRSF; SBUS would require some range mapping).

[breadoven]

@raphaelcoeffic Agree. The ELRS people would know if this is possible or asking too much of current RC links.

[gagarinlg]

Yesterday I learnrd that ExpressLRS does not just transport the values we send to them but does some calculations on its own on them before they are transmitted, so the ExpressLRS teams needs to be involved, too

[wimalopaan]

This is a long-standing issue: https://github.com/EdgeTX/edgetx/issues/134

But after some years of experience now, I would say, that a transparent channel value transport (bit-precise) would be against the concepts of EdgeTx and all link-technologies present. Scaling is ubiquous: in EdgeTx, Link, Receiver.

In my opinion the only safe way is to use an out-of-band-channel to transport binary, unmodified data. This is e.g. implemented as crossfireTelemetryPush() or sportTelemetryPush(). Unfortunately ibusTelemetryPush() and others are missing. One could simplify the API to only telemetryPush() ....

In my opinion we should leave alone the channel transport. Users should use XXXTelemetryPush(), albeit this is not possible for all RF-Links.

[silicongarage]

This is an old issue, but I just ran across.

Since switch data is usually low bandwidth, what about encoding the data in a channel with a pseudo pwm serial packet protocol?

Data would be encoded with 3 different PWM values (LOW,MID,HIGH). Then the packet protocol would consist of a sequence of START/SYNC packets followed by bit DATA packets and possibly a CRC/CHECK value sent over the chosen channel.

As an example assume a fixed 8 bit (switch) protocol then would start with 4 START/SYNC packets, followed by the 8 bits of data (and no additional CRC/CHECK) and would result in a channel stream looking like this:

logical switches: 10011100 channel stream (little-ended):
mid,mid,mid,mid,low,low,high,high,high,low,low,high, mid,mid,mid,mid,low,low,high,high,high,low,low,high, (repeat)

As an example extension, the protocol could be defined to first send a fixed size bit stream to specify the number of following data bits. SYNC, LENGTH, DATA, CHECK, (repeat)

Of course packet/frame loss would impact the possible completed message delivery rate, but it may be acceptable for low priority delivery rates.