Wouldn't it be much easier to allow to setup bind channel per model ? ie it may default to 5, but you could change it to say 15 using elrs config script ? This way you could easily align elrs arm and BF arm for example

Wouldn't it be much easier to allow to setup bind channel per model ? ie it may default to 5, but you could change it to say 15 using elrs config script ? This way you could easily align elrs arm and BF arm for example

This was of course the first idea but after a closer look this is not the best of all concepts. There are a number of reasons why this is not a solution. One obvious reason is it's still wasting one channel. What we truly were after was the separation of arming from RC channels as an add on option to the classic channel 5 based arming. Message based arming allows using up to all 16 channels for PWM outputs and serial data streams like SBUS. Other reasons are more subtle and buried in the way the OTA protocol works.

I think the main problem is that we have conflated ARM (on the vehicle) with "activate" on the transmitter module/receiver where "activation" does a few things like enabling the Dynamic Power algorithm and on the receiver, sending the ARM command to the DJI Air Unit, and potentially other things.

But this PR would mean that for a simple drone, user would have to configure a channel for arming BF, and an SF to activate ELRS. Doesn't sound like progress to me ?

And for fixed wings, users would need to add an always ON mysterious SF so they can use CH5 normally.

I'm all for fixing the ch5 issue, I just think that's going to confuse users even more

But this PR would mean that for a simple drone, user would have to configure a channel for arming BF, and an SF to activate ELRS. Doesn't sound like progress to me ?

No, the default setting for Arming is "Channel mode" and it stands for "use RC Channel 5 based arming" unchanged to the way you do it now. For a simple drone you'd do exactly the same as you do today. Define your CH5 mixer with a switch attached to set channel 5 to 1000/2000us and that's it Leave arming mode to its default Channel mode. No SF needs to be defined.

And for fixed wings, users would need to add an always ON mysterious SF so they can use CH5 normally.

I don't know what you mean by always ON. To use channel 5 as a regular proportional channel in the full-res modes but still be able to control arming you'd set arming mode to Function, define a SF Arm, define your trigger (e.g. physical switch) and enable it. Arming is now separated from Channel 5 and done via the switch you defined as trigger. No channel lost for RC control, No re-mapping required (which is really confusing for most users).

But this PR would mean that for a simple drone, user would have to configure a channel for arming BF, and an SF to activate ELRS. Doesn't sound like progress to me ?

The way I understand it, for flight controllers everything stays as is - arming mode is channel, and channel 5 is used for arming. No SF required.

For fixed wing indeed most people may just define an always on SF. So maybe a 3rd arming mode, "always" may be useful? But this will right now block changing stuff in the LUA...tricky!
Can we be "smarter" about arming the system in EdgeTX or ExpressLRS, something like SNR dropping below a threshold for the first time since the model was selected (just an example)? Similar to auto power but sticky.

So we arrive to the same conclusion, fixed wings pilots will have to do for each model an always on ARM SF (meaning trigger for the SF is ON in Etx) to free ch5 use. I’m sorry, but as a fixed wing pilot, that’s everything but logical or even simple to understand.

Since I don’t fly drones, are drones pilots expected to use this SF, or is it only for fixed wings/cars pilots?

Also, keeping arming name is wrong since it has nothing to do with arming craft?

I would much prefer something like:
ch5: arm/analog, and when analog is choose, elrs activation is always activated

You need to understand the concept of"optional add-on". No one has to use it, you can use it if you want to benefit from it. The clear benefit of arming mode Function is to free up channel 5 for RC control while still being able to control the armed state.

I also feel you need to understand the difference between arming the TX module (disable/enable certain TX module features) and why this is important (e.g. dynamic power) and arming a drone (spooling up the motors). Read @pkendall64's comment above again.

And I also think you misunderstand the purpose of the Arming: Channel/Function setting. This setting tells the system which arming method to use. RC Channel 5 based or SF Arm based. It does not deal with the armed state itself. This is done depending on the mode chosen. Either via the value of RC channel 5 or the state of SF Arm. If like what I suspect your fixed wing setup doesn't care about arming and wants to have the system permanently in the armed state (which is valid but not recommended) you can do this by setting the SF Arm trigger to ON. I personally set the trigger to a logical switch representing some sort of on-gorund/in-flight status (gear in, altitude > 20m, tow hitch closed, heli idle up on, ...) but you can also set the SF to permanently ON if you want.

To answer your question:

Drone pilots with existing setups: don't need to change anything

Drone pilots doing new setups: can still do it using the Channel 5 mixer setup like they'd do today. They could choose to use arming mode Function and control arming via SF Arm (no Channel 5 mixer required) . It'll work fine, but there's no real benefit in doing so.

Fixed wing setup: You can do two things.
a. Do what you did so far (don't use the add-on), i.e. control arming via the Channel 5 mixer (leave arming mode as Channel, no SF) but you won't be able to use channel 5 for RC control and control arming independently
b. Set arming mode to Function and define SF Arm. This way you can use channel 5 for RC control and are able to arm/disarm the TX module(!) as you like. Depending on a manually controlled switch, any logical condition or even permanently on or off.

This PR btw solves the problem many SBUS users have. Re-mapping channels on the receiver (e.g. via WebUI) doesn't change the channel order in the SBUS stream meaning users of older FCs and FBL expecting a certain channel order won't work with ELRS.

AFAIK lua allows to pickup any input, not just channels therefore all this logic can be kept in lua without touching edgetx.

So if this is all about enabling the Dynamic Power algorithm, isn't the logic reversed, and could be fixed as part of this change ?

If I understand correctly, fix wing pilots HAVE to proactively "arm the tx" for flying, you need to do something specific to your model (either fix ch5 value or use the SF) vs any other system to simply fly safely. That makes little sense to me as a fixed wing pilot.

I think it would be much much easier to understand if it worked the other way around, where you have to activate a SF if you want to "reduce" your transmitter power, kinda "pit mode" thing, otherwise, if nothing it done, it works "nominally/safely"

It's more than just enabling Dynamic Power. Theres other things as well that the TX module does.
Like disabling the gyro auto-sleep mode, disabling bump-to-share, disabling certain functions on buttons and OLED menu and Lua script, such as sending VTX channel change commands, entering joystick (BLE) and wifi modes. There are probably others I'm probably forgetting as well.

It's also not just fixed-wing pilots that have to "arm" the module, it's all pilots. It just happens that multirotor pilots need an arm and it's nice to share the TX "arm" and the multirotor arm.

It's all great, but all this assumes users know they need to "arm the TX" which most absolutely don't. You use companion or radio wizard to create the model, you get a model from a friend not using elrs, basically almost every scenario, you check it thoroughly, go flight it, bang your doomed.

Well, that is really a failing on the users part then, isn't it? As this has always been a part of ELRS, and has always been explained the quick start guides, videos, etc. Any radio system has idiosyncrasies... i.e. I could easily pick on Spektrum, which had a rigid TAER order, because the first channel would always go to 988us (or thereabouts) on failsafe... as well as no (not zero, no) output on the throttle channel while the receiver was booting up and looking for the TX - so was not suitable for use with some stabilisers, ESCs and use cases. It is really up to the end user to learn the specifics of the system they are using before doing stuff with it, especially if they are using models given to them by someone else, as there is bound to be something that needs to be changed when changing RF systems.

I get that the ch5/arm requirement is something ... unique?... to ELRS (which, IMO, at the end of the day is a good thing, as why bother having different RF links if they are all the same? Dare I say bring back the reed sets? 🤣 )... but we should not be aiding and encouraging ignorance and incompetence - there is enough of that in the hobby already, and IMO it is dragging it down, not lifting it up. But more importantly, will the craft still fly/operate if not "armed"? Sure will. Will it fly as far? Nope. Will that in most cases be further than BVLOS (which is illegal in most jurisdictions around the world without specific accreditation and training)? Yes. Will the transmitter tell the operator to stop being an idiot, and not fly out RF range? Probably will. Will they listen? Probably not... but they'll still blame the transmitter 🙃

I'mma gonna butt out now... I've had my 2c rant for this PR 🤭

I've had my 2c rant for this PR

Thanks for your replies. I think your $100 rant was more about @3djc's fundamental discussion which had no place here in the first place. Let's move on.

It's all great, but all this assumes users know they need to "arm the TX" which most absolutely don't. You use companion or radio wizard to create the model, you get a model from a friend not using elrs, basically almost every scenario, you check it thoroughly, go flight it, bang your doomed.

If you want to continue voicing your concerns about the general ExpressLRS arming concept you're welcome to do so. Please open a new discussion in https://github.com/ExpressLRS/ExpressLRS/discussions. Good ideas are always welcome.

Tested almost everything I could think of, colorlcd, b&w, fullres, regular, with and without CH5 mixes, all good
Untested: EdgeTX Companion, GemX modes (but those should be fine since they use the same OTA)

TX16S internal, Tested with Betaflight
TX dynpower 25mW
333Hz
  TX set to Arming: Channel
    No CH5 mix: CH5 output 1500, never arms PASS
    CH5 mix: CH5 output is fullres, arms when CH5>1500 PASS
  TX set to Arming: Switch
    No CH5 mix: CH5 output 1500, arms when switch active PASS
    CH5 mix: CH5 output is fullres, arms when switch active PASS
      8ch is exactly 8ch (no longer 9ch) PASS
      12ch is 12ch PASS
      16ch is 16ch PASS
250Hz
  TX set to Arming: Channel
    No CH5 mix: CH5 always 1000, never arms PASS
    C5 mix: CH5 goes high if mix > 1500, arms when high PASS
    CH5 used for arming: PASS
  TX set to Arming: Switch
    No CH5 mix: CH5 output = Switch, arms when switch active PASS
    CH5 mix: CH5 output still = Switch, arms when switch active PASS

Zorro Internal, Tested with Betaflight
Tested D500, 333Hz, all above test matrix PASS

Tested with external channel dump utility
  100Hz fullres modes channel values
    8ch PASS
    12ch PASS
    16ch PASS
  50Hz
    wide switch mode PASS
    hybrid switch mode PASS

EdgeTX Extras:
Setting is stored per-model PASS
Default to CH5 arm mode PASS

Does the RX also output the new, extended RC_CHANNELS format on the crsf-serial-output to signal the dis/arm state to other devices (FC)? If not, it would be best to make that a configurable option on the receiver side.

If no RC channel is used to signal the dis/arm state, how then?