Abstraction layer between common functions and physical controls

[jmxp69]

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 are certain nearly universal capabilities for just about every model configuration when the associated feature exists on a given model, i.e. grear/flaps/gyros/fbl/fc

• Throttle cut
• Rates
• Timer resets
• FC mode selectors
• Flaps
• Gear
• Idle up1,2,3
• Rescue
• Volume
• Screen brightness
• Timer reset

Today, these features are all easily enough to define on a radio. 100% no problem. The issue comes up when we try to share model configurations. Where I might use SB for rates, someone else might use SA or SG. Where I might use RS for gear, someone else might use SF. Where I might use LS for flaps, someone else might use RS etc etc...

Describe the solution you'd like

I propose is the ability to define a function like throttle cut to use the hardware I want, then for the model configuration to use the function "throttle cut" irrespective of the hardware used to define what a throttle cut is.

So if I use SH for my throttle cut and you use SF for your throttle cut, I can still share my model configuration for you because the model configuration refers to "throttle cut" and not SF or SH. And when you load my model configuration, your radio will cut the throttle using the throttle cut function irrespective of the physical control I might have used in my model file.

In other words, I'm proposing an abstraction layer for common functions to facilitate simplified sharing of model configurations.

Describe alternatives you've considered

Mixing prescription drugs with hooch...

Additional context

Appreciate the consideration gents. The EdgeTX team is one of the best assets of the RC Community!

[philmoz]

If I understand correctly you would need to map a switch/pot/slider to control a function (e.g. throttle cut) in the radio setup. What happens if you load a model on a radio where there is no such mapping?

As an alternative I wonder if we could do this using the existing name field for switches, pots and sliders.

If the name field is populated, save it to the model YAML file, alongside the switch name, wherever the switch is used.

When the model is loaded check the saved name against the radio configuration and alert the user if there is mismatch:

• radio has no switch/pot/slider with the given name
• radio has a named control; but it does not match the loaded model
• radio has a named control; but it is a different type

The user could be presented with options based on the mismatch (e.g. use radio control, select a new control to use, use same control as model file, etc).

This might be tricky on B&W radios as we are pretty tight in FLASH space in some cases.

[jmxp69]

Today if we set a special function to play a track on one radio, then we save the YAML to a different radio, the play track special function is present, but the track name is blank. I would expect a similar behavior.

Without having the development background to help arrange the logic, I'll explain how I would expect this to work as an experienced user.

My friend sends me his YAML for a fixed wing 4 channel plane. He defined these Functions:

• Throttle cut
• Dual rates
• Timer on trigger

On my radio, I only have these Functions:

• Throttle cut
• Dual rates

In his Functions page he has:

Throttle Cut = SG down

Rate Switch = SB

Timer Trigger = L02 (L02 = AND Tele SGup)

In his model config he has:

Special Function: SF1 = Override Ch3 -100 = Throttle Cut

Inputs: Ele 100% Rate Switch Up Ele 80% Rate Switch Down

Model settings -> Timer 1: Switch = Timer Trigger

On my Functions page I have:

Throttle Cut = SH down

Rate Switch = SC

I copy to my SD card and select in model selector and a screen pop says:

Functions defined but not configured:

• Timer trigger (I can dismiss or change my setup)

Where his model configuration uses Throttle Cut, my radio throttle cut will work using SH down.

Where his model configuration use Rate Switch, my radio rates will work using SC.

Where his model configuration uses Timer Trigger, my radio will not trigger a timer because I haven't defined the function.

[jmxp69]

The other advantage of doing this is I can define my throttle cut one time using a combination of features (logic/special functions) but it becomes a variable I can use anywhere and anywhere I use it, it behaves the same way.

I would really like the ability to define any function using functions like a voltage sag function:

Voltage Alert = Throttle cut off and x.xxV < RxBat < y.yyV for 6.0s. SF1 = Voltage Alert - Play Sound Alarm 2s

[pfeerick]

I was just thinking about this on the weekend (as I copied some models from the TX16S to the T15), and needed to move switches around as the TX16S has switch order A-B-C-D, whereas T15 is A-C-D-B (odd in the case of the T15, but probably because it's T14 sibling has 2POS A&B, 3POS C&D). And SC on TX16S is my flight mode switch, so naturally that one would move! :rofl:

How about if there was an extra section in radio settings, not quite sure what to call it yet... re-assignable sources?... whereby you would have another set of sources that you can map in turn, to any switch, pot, slider, stick/axis? They would be sequentially numbered, and nameable, and with it being in the hardware settings, would be radio specific. And would be usable everywhere else you can uses sources - ie. inputs, mixes, logical switches, special functions, etc. Thus, instead of using SC as the source for mix line 6, you would use RS2: MODE, which on the TX16S would be SC, and on T15 would be SD... And if RS2 isn't defined, the mixer line is non-functional/1500us. And would become functional as soon as you assign RS2 to a source, or manually edit the mix line.

Just something to think about using some of the existing concepts, rather than adding yet another field to the mixer/input screens, or having it tied to names needing to match up exactly, or even matching when it shouldn't.