Change behaviour of Trim buttons to behave like any other standard button

[JimB40]

There is a large user group now that don't use Trim button in a way they were coded.

Example is quad's pilot. They switch off trims not to mess with 4 basic channels and use Logic Switches, Inputs with MAX and GV to change those unused Trim Buttons to simulate behavoiur as ... Buttons. :)

Concept is to re-code those T1,T2,T3,T4(T5,T6) to work as standard buttons. Then to give user possibility to define how it behaves. One way of usage will be fine trimming of four standard channels.

Related discussion

1723

[pfeerick]

I wouldn't expect to see this in 2.8 unless you intend to implement it :-P And keep in mind that's firmware AND companion support.

So, if I'm a construction equip user, and want 8steps, 1200, 1100, 1300, 1000,1400,1600,1500,1700... Where do I fit in in your proposal? Yes, that is a completely fictitious made up example, but this is exactly why I suggested using a curve... It allows for abritary control over number of steps, order and value.

I can see potentially the need for a whole page UI to configure this if we don't scope it properly... Which trim buttons control the up and down (because why should it be either end of a trim switch?) "Trim* channel assignment... Two sets of "trims" could feed into the same channel, but different rates. Number of steps, step positions.

Perhaps we should be thinking this more as "virtual channels" i.e. exposed like the TR trainer channels, with the trim buttons as the inputs, with several presets that equally divide and a curve option for complete customisation?

[JimB40]

Think positive. Trim is just another -1024/+1024 output that is currently bound to specyfic channel to adjust it. 99% percent users will be happy with 2 & 3 positions, but I have nothing agaist coding variable that will divde scale to 10 :) You know I don't code but raised feature "not to forgert". Now going to hunt for dev having spare time that is like hunting for unicorn lastly.

[pfeerick]

I was... that's why I didn't say 2.9 :-P

Ok, so when the trims are disabled / trim channels enabled, in addition to the Tu, Td, etc, etc, inputs, there would be TRM1, TRM2 (for want of better acronym) channels, one for each trim control pair... and then you have a dropdown for each trim, with the number of steps for each channel?

[JimB40]

That's exactly what I thought of. Names can be T1,T2 etc as radio mfgs ussually name it like that.

[Eldenroot]

Really coool suggestion!

[rotorman]

Whereas, most presently in ETX supported radios indeed use T1, T2, ..., Tn naming for trims, there are some future exceptions to keep in mind. E.g. PL18/PL18EV are using TR1 to TR8. Also on NV14 T1 to T4 are not labeled out, there is just a left and a right "TRIM" hat-switch. (Irrespective of the naming, I like the idea of being able to arbitrarily assign the trim buttons to do something completely different).

[pfeerick]

Indeed. Off to top of my head I can only think of probably two radios out of over a dozen or more of the supported ones that actually label the trim keys... i.e. minority, not majority. But for want of a better name as the default, it should work.

[raphaelcoeffic]

So, if understand correctly, this is about:

• switching off use of trims everywhere (mixes, inputs, etc)
• but still make the trim value itself (persistent value, one per flight more) available for other uses

This is "sort of" already there, but it requires the user to pay attention and do the following:

• disable trim via option everywhere (mixes, inputs, screens)
• the trim values themselves are already available for any other use

So this looks like a simple UI feature that would tweak a couple of default value (mixes / inputs when added and for new models). Is that correct?

[pfeerick]

Essentially yes. but also adding the concept of having a configurable/discrete number of steps to move the full input range. i.e 2POS, 3POS, 4POS etc ...

To do this right now, I would turn the trims off in the flight modes, and then use 2SF + 1GV to mimic this, but that is for each trim pair used.

[raphaelcoeffic]

Essentially yes. but also adding the concept of having a configurable/discrete number of steps to move the full input range. i.e 2POS, 3POS, 4POS etc ...

To do this right now, I would turn the trims off in the flight modes, and then use 2SF + 1GV to mimic this, but that is for each trim pair used.

I think we can have it simpler. But I like the idea of simulating xPOS switches with it.

so after function switches we get virtual switches?

[pfeerick]

I think we can have it simpler.

Not really, as this is specifically what Robert is asking for ;)

But I like the idea of simulating xPOS switches with it. So after function switches we get virtual switches?

Yes. It's so that a trim "channel/input" can have a fixed number of steps... so you can use a trim "input" to mimic a 3POS/4/5/whatever switch, just need to click it more times.

[JimB40]

Okay so about naming: Regarding sources we have now hardcoded: trim-ail,trim-ele,trim-rud,trim-ele,trim-t5,trim-t6 - btw what control surface is t5 or t6? ;) Even this shows "plane-legacy" i would not change them or touch as most probably they are used in all sort of places including LUA scripts. @jfrickmann may confirm or deny.

That leaves us with naming convention for un-binded T-switches like

1. existing convention -> trim-t1, trim-t2, trim-t3, trim-t4, trim-t5, trim-t6
2. changed -> t1, t2, t2, t3, t4, t5, t6

I would opt for option two as other hardware switches have simple names: sa, sb, sc, sd etc and those names are used all around various functions in system. Also we have inputs called trn1, trn2, etc for trainer inputs so naming trm1, trm2 is IMHO to close and will cause different kind of typo errors.

[JimB40]

I would not call T1,T2 virtual as they are very physical :) In fact they could look physically as any other 3 position switch with UP and DOWN momentary position. BTW always puzzled me why they are treated as buttons (keys) not switches @rotorman? you know history? ;)

I understand that at the very beginning of OpenTX nobody thought they can be generic. So implementation is TRIM-focused on various levels. This includes integration with Flight Modes, Pitching sounds you cant turn off etc etc.

Still correct me if I'm wrong they are just generic hardware buttons that can be binded to channel. Just because of legacy someone decided they will be treated in software as "special" buttons that corrects chosen channels in certain way.

I'd like to see plane or glider pilots & devs like @jfrickmann to have a word about that change as this seems to be deeply integrated in various areas os system in way it is now ie. Plane control surfaces trimming.

[JimB40]

Little off-top but connected. This touches top-level or core-assumption topic @lshems mentioned long ago and as always it legacy.

Fact to verify easily is than more than half of current EdgeTX users don't have bloody idea about Aileron, Rudder or Triming control surface. So one of difficulties for starters is that you have Manual saying "too accelerate press Throttle pedal" and you look at your bicycle wondering where this "Throttle pedal" is. :)

I like idea of Operating system being generic. AUX1? nope just CH5. But l know touching legacy here is straight way to make flame-war :)

Still maybe using Kazein step-by-step way we can make it generic. Having user-cases (Plane, Glider, Quad pilot as top most used) that adjust naming to be familiar for those groups.

[rotorman]

BTW always puzzled me why they are treated as buttons (keys) not switches @rotorman? you know history? ;)

I do not have a very long history with OTX, but possibly @3djc might be able to answer you.

[JimB40]

Yes. It's so that a trim "channel/input" can have a fixed number of steps... so you can use a trim "input" to mimic a 3POS/4/5/whatever switch, just need to click it more times.

Exactly.

1. Short implementation would be just adding option that pressing UP or DOWN any of T1.T2,T3,T4,T5,T6 knob will make coarse predefined jump. Then no need to disable anything in Flight Modes as trim works but it's kind of castrated to 2,3,4 positions. But that will need user anyway to remember to unbind trims from CH1-CH4 as let's say with only 2 states option (max and min) unintended press will have rather unpleaseant consequences.
2. Long and better is that we have T1,T2,T3,T4,T5,T6 option to set it in 'switch' mode. Switching to this mode this will automatically ignore this Trim button as input for other channel correction (wherever applicaple). Instread Trim knob will start behave like multipos switch with selected number of positions.

[pfeerick]

I would not call T1,T2 virtual as they are very physical :) In fact they could look physically as any other 3 position switch with UP and DOWN momentary position. BTW always puzzled me why they are treated as buttons (keys) not switches @rotorman? you know history? ;)

And that went right over the top of your head. :-P They are "virtual" because they are two physical momentary buttons, which would be mapped to be a multi-position input. As opposed to a switch, which (except for the momentary switches) stay where you put them. And even then, the momentary switch directly controls the channel. Just like the Tu/Td, Eu/Ed switches ... you know, the actual trim buttons which you can access right now ;)

I would suggest there is no short and log implementation... step 1 is allowing them to be controlled trolled separately in line with implementing #1723. Then 2) is also allowing for them to be detached from trim functionality, where you choose your steps. In both cases, at the model level.

[elecpower]

As a fixed wing pilot I use the trims, except throttle, for every model to balance out air surface irregularities (usually from crashes) and engine torque. To get aileron differential calculation working better I do de-couple the aileron trim and add back after differential calculated #1244 Also use trims to sub-trims function until I have time to make mechanical changes and make the full trim range available. So for me, current trim functionality including variable trim step would need to be supported. That being said de-coupling the trim switches and supporting variable configuration would also support other uses for the radios such as robotics, cars, boats, etc. The proposed change would appear to simplify cross trim coding which has proven problematic based on issues raise in ETX and OTX by breaking the current stick and trim pairing. There would need to be a default implementation for those new to ETX who for example have come from a proprietary radio or those new to ETX with a 'simple' interface.

[jfrickmann]

Things to consider:

• 99.9% of fixed wing pilots use trims
• You can uncheck "include trim" for the INPUT line if you don't want to use it
• You can use trim as an INPUT source if you want just the trim as input source. So no need to create new TRM1 etc. channels; they are already available.
• There is a SF to override trim to adjust a GV
• You can read the trim buttons as a switch in Lua with getSwitchIndex and getSwitchValue

We should be careful not breaking stuff that works or adding redundant functionality to confuse users.

If you want to give me a list of the "new" things that you want to do with the trim buttons, then I can go home and make you a setup tonight that shows you how to do it with the existing system, if possible.

[raphaelcoeffic]

@jfrickmann this is basically about UI, nothing more ;-) The idea is to have some UI setting that would apply certain defaults. In our case, we won't use that settings, and that's it.

[JimB40]

Guys to be clear. I know that planes or gliders pilots are growing and satisfied group of ETX user base. So 100% any solution we will cook must retain existing functionality for plane and glider pilots group.

However we've been talking for some time that if more than 50% nowadays flies quads wirh ETX, UI and OS should adjust based on type of model selected to lower initial learning curve or at least make it less steep. And make UI less cluttered from things they will not use even once. That was written in initial draft back in 2021 as OS core change.

1. If I choose plane. Trims work as trims, Flight Modes are displayed, Heli tab is hidden, Global variables are bound to eight Flight modes etc.
2. If I choose quad. Trims work as multipos switches. Flight Modes & Heli tab are hidden, maybe (just idea) there is only one Flght Mode 0 and Global Variables are bound to this default Flight mode etc.

User friendly system (UI) shows only what is needed for given user type not every possible option.

PS. Not 100% percent sure but #1692 is intial draft to configure UI per model type? @pfeerick

PS2. @jfrickmann I know that flying quad I can do almost everything reconfiguring OS and using "hacks". Just IMHO it's time not to push this group to start form using all kind of "hacks" to use OS efficently. :)

[jfrickmann]

Why not make a user-friendly model template for quads? We can make a model template with the basic setup, a wizard script for initial config, and widgets or telemetry screens for further model configuration? Basically, we could make it so the user does not have to dig around in the underlying menus at all, if he/she is just using standard stuff!

[JimB40]

As @raphaelcoeffic stated it's 95% about UI 5% about slighly different use of existing hardware. Short answer is to declutter. Flight Modes are solely planes world. Never seen anybody flying quad using it. Still you have settings in every input to select if input works in that FM. Or Side in same input , or ... I will tell you full list after review. :)

[lshems]

Why not make a user-friendly model template for quads? We can make a model template with the basic setup, a wizard script for initial config, and widgets or telemetry screens for further model configuration? Basically, we could make it so the user does not have to dig around in the underlying menus at all, if he/she is just using standard stuff!

Lol. Have fun and just fly!

[jfrickmann]

Lol. Have fun and just fly!

Yes, I know that is something that you have been advocating for a while, Guido 😉

As for the proposed UI changes, I am not the one who can judge the merits, as I have never owned a quad. I just wanted to make sure that the existing possibilities had been considered, so you do not reinvent the wheel. And I am of course fine, as long as it does not mess up existing setups.

If anyone wants to make a nice template for a quad that makes it easy for beginners to get in the air quickly, then I will be glad to help out if I can.

[elecpower]

What may help better align the UI to suit the model and hide complexities for newbies prefer to maintain settings in template and wizard modes would be to store a type for each model indicating what the model is controlling eg quad, heli, 3D plane, glider, flying wing, fixed wing, robot, car, boat, custom (I know best mode), etc.

With the model type known, then for example for a glider then to add differential could be a selection but would not show for a quad. The differential edit would show those fields that manage it. Same for quad, it would have a list of quad specific actions.

Combining this with the initial setup templates would hide the unnecessary and complexities (flexibility).

If you want to walk on the wild side then custom type is available.

[lshems]

Issue is that you end up with giving support on how that new setup template is working and how it can be tuned to get stuff done that is not in that template.

In the end you get a complex template, that doesn't allow the majority of users to do things beyond that template.

A template setup with custom GUI only works if you can close certain things from being user accesible from the edgetx user interface.

[lshems]

But that is all off topic.

[elecpower]

If we remove more compiler options and move the choice to the UI we can streamline the UI further. eg Flight modes Y/N Global variables Y/N Timers Y/N etc

[elecpower]

But that is all off topic.

Yes however trims are intrinsic to the operation so cannot be changed in isolation as evidenced by the discussion

[jfrickmann]

The more features we bake into the underlying system to accomodate for users with various specific needs, the more we end up with a radio like everyone else, where templates for specific usage cases are baked in, and if you want something else, then you are SOL.

I therefore believe in an open system, where the underlying menus and programming facilities are as generic as possible, and then we can add templates with scripts to provide simple user interfaces for specific model types.

So in principle I support JimB40's suggestion here, as it is making trims more generic. As a matter of fact, there is very little difference between trims and GVs, as both can be FM specific, and there is a SF to adjust a GV with a trim button. So in the extreme we could get rid of trims and increase the number of GVs to e.g. 32 plus add optional adjustment buttons in GV config.

But I also know from personal experience how some users take it when you move their cheese e.g. by modifying the way that Lua manages color 😉 So I would be careful not to change things too radically!

[lshems]

Fully agree. But let's take it one step further then, and stop making a difference between a switch and an analog input as well. So you can finally use an analog input directly as a switch. Have the switch logic trigger on say +/- 33 % and you have a nice shortcut to use a slider as a switch without extra logic.

[jfrickmann]

You can do that with a LS

[lshems]

3 of them!

[lshems]

While the logic would not even have to change.

[jfrickmann]

The way that OpenTX has been designed from the ground up is with two separate indices for value sources and switches. I have made those available to Lua with getSwitchIndex/getSwitchName/getSwitchValue and getSourceIndex/getSourceName together with getValue. I think that makes sense, and it would require a total rewrite of the code to mix them all up, and I don't know what I would do with a telemetry value like RxBt as a switch...

[pfeerick]

I'm about to get my stomping boots out :-P IM(VIP)O ... 1) Trims are going nowhere - just because quad flyers think they are the bees knees, they have been like this more than 50 years, so are not going away, and are still relevant for a big portion of the users. 2) This is not about changing the default. The default would be, trims operate like trims, as the userbase is familiar with 3) This is about adding options - you can turn OFF the trim behaviour, freeing up those controls as inputs for a channel. But because they are virtual inputs (rather than being able to read the position of the trim directly like a switch), they need a little more TLC... configurable number steps/positions. 4) This can then be presented in the main UI as options for trims, and also exposed via lua so the wizards/templates can deal with it. Use the Quad template and wizard... Jitter filter is turned off by default, and trims are disabled. Use the plane template, ADC jitter is on by default, trims are on. Do a blank model, trims are on by default. But all the options are there in the UI.

So lets not deviate of from this for now, m'okay? 😁

[JimB40]

Haha I was sure Peter will step in. :)

• Father I want to trim with potentiometers
• Nope we will trim with trims
• Father why we have to trim with trims?
• Because my father was trimming with trims.
• Why your father was trimminig with trims?
• Because his father was trimming with trims
• Father...
• Son just fly ... Trims are default. Period.

Okay whatever. My main goal (not directly connected to this issue) is to declutter UI as number of options for each user case will increase. What is not needed is not visible. And thats perfect with templates. Beginers will use templates without need to know there is GV or LS set to achive goal. If something is not visble it doesn't mean it doesn't exist.

And there can be always UI option "show me everything what's under the hood"

[lshems]

Funny, of topic:

When I have a nice idea at work, they often say: no, not that again, it has been discussed a thousand times.

My reply, given the new circumstances: there is sound reason to discuss it for the 1001th time, so better get used to that.

[JimB40]

But I also know from personal experience how some users take it when you move their cheese e.g. by modifying the way that Lua manages color 😉 So I would be careful not to change things too radically!

I know, i do experience it pushing boundaries. So small steps that are easier to swallow and of course keeping existing implementations not make people angry that thay can’t do anymore as grandpa did. 100% I will be scapegoat once we start introducing new UI :)