Remapping option for channel 5 in SBUS

[apiening]

I have an airplane from FMS which has a stabilizer system (Reflex V2) which accepts SBUS. I enabled SBUS output for my RX (ELRS 3.3) and the control link works fine.
However, this stabilizer uses channel 5 with a three position mode switch to select between stabilizing modes (auto level, optimized, off). So when I configure it this way, I also disarm when I choose auto level stabilized mode.

I can assign the PWM outputs freely with ELRS, but is there a chance to remap channel 5 for the SBUS output?

[ZZ-Cat]

I second this.
I have an OMPHOBBY M2 V2 helicopter with either SBUS or DSMX serial inputs to the flight controller, and I am about to take the dive into ExpressLRS with a HappyModel EP2 receiver, and install that in my M2.

According to my information, I can set the receiver up in the LUA script to spit out SBUS (my intention here is to use the SBUS output from the receiver to the flight controller).
However, my concern is with my M2's flight controller where Throttle Hold (which is another name for "Disarm") is on Channel 5 and is HIGH for it disabling the motors (IE Main motor and tail motor) or LOW for enabling the motors and the control loop.
IIRC, for ExpressLRS, it's the other way around.

My question to the devs is: Would it be possible to make Channel 5 a bit more flexible, in the sense that it can be treated like any other proportional channel when the Full Resolution switch mode is active, and the receiver is outputting any of the supported serial protocols?
Either that, or make it optional for Channel 5 to be treated as such?

[Kjblootens]

I'm seconding this. Can we remap sbus output just like PWM please 🙏

[Mikey1968]

Can you make it so we can reverse arming in the Lua
Cause I have a gyro to where when I turn it on the arming turns off, when I turn gyro off , the arming comes on. I also hope you guys change arming to something we can pick as a ch instead of ch5

[apiening]

Can you make it so we can reverse arming in the Lua

Honestly I thing that this would be a workaround, while the true issue is that channel 5 cannot be used freely.
Wouldn't it be more consistent (and probably easier to implement) to just enable the option to swap CH5 in the S-Bus stream with another channel, which can be selected?

The fact that CH5 is used for arming, is the only reason why one would remap the channels in the S-Bus stream. Or do I miss something?

[SweaterBabyJesus]

I'd like to double, triple, second this please.
I would like to use the SBUS option from my Radiomaster ER6 rx with an H1 flight controller but the H1 requires 3 positions on ch 5. Pretty please make ch 5 more flexible when it comes to SBUS.

[SweaterBabyJesus]

Found a solution for my application, might help others. This page - https://www.expresslrs.org/software/switch-config/ - explains the switch configurations. In my application while using the SBUS output I need ch 5 to have full resolution. I am not flying a quad so my motor arming is done on another channel, do not have a VTX, don't use bump to share etc. etc.
So I set my packet rate to 333Hz Full, my switch mode to 16ch Rate/2, my tx power to 100mW and turned off dynamic power and hot damn! I got what I needed!

[spinolio]

Add me to the list of those wanting SBUS channel mapping. I just ordered an ELRS radio and a few receivers to see how I like it. I already have two other radios with 4in1 modules and a significant collection of receivers using various protocols. They work very for FW LOS (fixed wing line of sight) flying, so I'm trying ELRS more out of curiosity since I find radios to be an enjoyable part of the hobby. Having a separate ELRS transmitter will also keep things simple until they eventually (hopefully!) they fix the CH5 issue. I don't want to have separate templates for ELRS models just because CH5 is tied to other functionality.

For serial channel mapping it would be most flexible if it was separate from the PWM output mapping, but another option would be to use the Input mapping already available. In that case they should not gray out the Input selectors in the ELRS Web UI for CH2 and CH3 when the serial output option is selected. Then down where the particular serial protocol is chosen they could add a checkbox to remap serial according to the Input mapping already specified above.

While the flexible mapping would allow better CH5 workarounds, it would be far better if they would just separate the arming function from the standard channels. Looking at the OTA (over the air) data structures for ELRS in github, the AUX1 bit (aka Ch5) is already separate from the rest of the channel data. There's no good technical reason to consider this to be a standard channel.

I understand that back when the project started they had to use a channel value in the transmitter to control the arming because radio producers weren't going to modify their firmware to support a new and unproven open source project, but that is no longer the situation. ELRS now has the market clout and vendor support that warrants direct support from EdgeTX. A simple modification could allow configuration of an arming switch as just that -- an arming switch. Not CH5 or AUX1. The arming bit would then be set directly by the switch, not by CH5 as controlled by a switch. Naturally that same switch could still be used to control CH5/AUX1 if needed for some backward compatibility situations, but by default we would just have regular channels 1-8, 1-12, or 1-16, free to use for any purpose.

[mha1]

Most of the devices can be used not only with SBUS but other serial protocols too. Check your device spec if it supports Graupner's digital serial protocol SUMD. I have implemented SUMD with ch5 remapped to ch8 (ch5 and ch8 swapped) to provide a linear 7 channel sequence for devices with fixed channel assignment. SUMD is readily available in 3.3.x. You'll find more here: https://www.expresslrs.org/software/serial-protocols/?h=sumd#sumd-notes

[spinolio]

Thanks for passing that along. Unfortunately the devices in question support SBUS or PPM, but not SUMD (FMS Reflex and Arrows Vector flight stabilizers). I have a feeling ELRS will eventually get a more elegant and/or flexible solution for channel configuration. 3.4? 4.0? Time will tell.

[mha1]

ok, for those who can't use SUMD: I did the same remapping (swapping ch5 and ch8) for SBUS in a branch based on 3.3.1. To use this you can build and flash the firmware using the ExpressLRS Configurator. Use Configurator as you normally would but select GIT COMMIT instead of OFFICIAL RELEASES. Copy/paste 8d7f415722db0aaadb2c8ab5614b30712e0e1300 to the Git Commit hash field. Fill in the rest of your data as you are used to.

[spinolio]

Thanks for sharing the hash -- I will use that! Is this on a separate branch that would need to be applied again to future releases? I'll take a look at the code. I've not looked through the ELRS codebase, but I might try to tinker with the channel ordering when I get my radio and receivers. I'm assuming there's an existing channel indexing array for mapping the Inputs to Outputs for PWM, and I want to experiment with using that to control serial channel ordering, too, but that's more out of curiosity since your solution will work.

[neilputt]

I also recently purchased a Reflex V3. By default, it uses channel 5 for flight mode switching - there is no option to change it. For fixed wing flying, remapping inputs & output channels over serial (especially channel 5) is important.

[Mikey1968]

All you have to do is change your settings in the express rs Lua and change it to 333mhz 16/2 and then ch 5 you can use for gyro , I use that as well. Arming isn't needed if your flying LOS

…

On Sun, May 19, 2024, 7:44 AM neilputt ***@***.***> wrote: I also recently purchased a Reflex V3. By default, it uses channel 5 for flight mode switching - there is no option to change it. For fixed wing flying, remapping inputs & output channels over serial (especially channel 5) is important. — Reply to this email directly, view it on GitHub <#2479 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWZHMI45M35EKKFQ7AD7LDZDC3DZAVCNFSM6AAAAAA7R2XAWGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIOBYGEYTG> . You are receiving this because you commented.Message ID: ***@***.***>

[neilputt]

I am aware of that method, it's a workaround though with compromise required on update rates and dynamic power.

[Mikey1968]

I don't use dynamic mode on my planes cause I don't fly far enough to make use of it. The 333mhz gets me miles of distance

…

On Sun, May 19, 2024, 8:03 AM neilputt ***@***.***> wrote: I am aware of that method, it's a workaround though with compromise required on update rates and dynamic power. — Reply to this email directly, view it on GitHub <#2479 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWZHMJ23CAPPZFUIUNWMMLZDC5MJAVCNFSM6AAAAAA7R2XAWGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIOBYGM2DM> . You are receiving this because you commented.Message ID: ***@***.***>

[neilputt]

There can simultaneously be an enhancement request and a workaround. One doesn't negate the other. You are describing the workaround, which is mostly good. I would like for the enhancement to be addressed, hence my comment. I could also just use the pwm outputs directly. But again, this would be a nice enhancement.

I understand this will require careful considerations for safety in scenarios where the arming switch is relevant. It may take time, that's fine. Onwards and upwards, right?

[Mikey1968]

Watch this video https://www.youtube.com/live/ARCfafma1rM?si=8cD-iv_xe6Bct0gN

…

On Sun, May 19, 2024, 9:15 AM neilputt ***@***.***> wrote: There can simultaneously be an enhancement request and a workaround. One doesn't negate the other. You are describing the workaround, which is mostly good. I would like for the enhancement to be addressed, hence my comment. I could also just use the pwm outputs directly. But again, this would be a nice enhancement. I understand this will require careful considerations for safety in scenarios where the arming switch is relevant. It may take time, that's fine. Onwards and upwards, right? — Reply to this email directly, view it on GitHub <#2479 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHWZHMKRFXXRLCZZNHJ44E3ZDDFYLAVCNFSM6AAAAAA7R2XAWGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TIOBYHA4TA> . You are receiving this because you commented.Message ID: ***@***.***>

[neilputt]

Already have. The enhancement request is still valid. I will stop responding now.