Independent trims for flight modes

Well, now I don't really understand, what do you mean. I've got my language barrier as well...

I think the difficulty lies in the two very distinct approach of the advanced and the standard UI. And now on the standard UI I mean all the other transmitters (aside with the er9x fw) and the original devo fw too.

In the standard approach every function depends on the hardcoded flight modes whether you want or not. AIL, ELE and RUD all have three/four different settings in their DR pages. So if I want to know, how the rudder behaves, I have to visit all the flight mode dependent DR pages of it (plus all the other rudder related pages, like program mix, etc), however I used to use one simple 1-to-1 rudder all the time. In our advanced UI it would be one simple mixer page, and I could be sure, that nothing else affects my rudder. So in such a case the advanced UI could be simpler...

About the 'virtual' switch assignment:
The standard UI has a switch assignment, and you don't have to (i.e. can't) assign switches on the function pages, because it is hardcoded (to the selected switch at least). For example if you would like the throttle hold to be reversed, i.e. to be on when RUD_DR=0, you can't do that.

However the virtual switch assignment, I'm talking about would assign concrete switch values, for example TH=RUD_DR, but it could be TH=!RUD_DR too. You could just use TH as the switch everywhere you want the throttle hold to be on, or !TH if you want to be it off...


EDIT: I think this post of mine caused the mixup. It was intended to show, what does a traditional flight mode configuration look like.
I don't like that approach, because it is limited, and is quite different from the advanced mixer UI we've got here, so my virtual (flight mode) switches would not be like that...
I hope it isn't confusing now...

I might not be clear enough, because I still feel misunderstanding here.

My version of flight modes/states would be absolutely compatible with the advanced mixer, since it is the advanced mixer itself. The only thing that would changed, that there would be some more options in the switch spinbox: the virtual switches.
Let's distinguish them with a special character, say '*'.
So in addition to the real switches, sticks and channel values, there would also be for example:
*FM0, *FM1, *FM2, ... for the flight modes;
*TH for the throttle hold;
...etc.

They would have a page, where you could assign real switches to them, but they would have defaults too, like:
*FM0 = FMOD0
*FM1 = FMOD1
*FM2 = FMOD2
*TH = RUD_DR
...etc.

(Actually they could have custom names too, but not neccesarily...)

deleted

deleted

Ah, why do I feel, that we started it again...
I would appreciate some help from a native english speaker, who understand me, but could explain it better.


I'll try it again in a different way:

- There would be no such thing as flight mode/state/whatever.

- There would be only virtual switch state assignment, which you could use on the complex mixer pages (and on the Expo&DR template, etc) instead the real switch values, which would make it more generic, and easier to adopt to other user's needs, or to other transmitter types with different switches.

- The '*TH' example doesn't mean there would be a throttle hold flight mode at all, but only means, that you could use it as the safety switch instead RUD_DR, or if you implemented the throttle hold as a last plus page of a complex mixer, then '*TH' could be the switch of that mixer page.

- This debate went off-topic, sorry for that.
The last post about 'Independent trims for flight modes' was this:
www.deviationtx.com/forum/3-feedback-que...es?limitstart=0#4866

- You should read that post again. It means, that not the flight modes would have their own trim value support, but the trims would have the 'flight mode' support, more precisely simply a generic switchable support, with which you could configure a 'flight mode' support if needed...


Both things could be implemented in various ways in my mind, but first we should debate the way it should work...

I would like to hear PB's opinion too.
After all, who's gonna implement it?

Before we go into the flight-mode discussion, can someone explain why this doesn't work:
set trim1 to fmode0 with up/down set to thr trims
set trim2 to fmode1 with up/down set to thr trims
set trim3 to fmode2 with up/down set to thr trims

now the thr up/down has 3 different variables. At the moment they all move together so you can't actually have 3 separate values. what you seem to want is for the trim to only be active when the channel is active. That isn't possible today, but I may be able to come up with something.

I need to spend some more time reading the flight-mode discussion in detail to understand exactly what it means before I respond to it.

Yes, this is what I'm talking about.
Each trim setup would need only an optionally configurable switch, and then it would only count into it's variable if the switch is on.
This way we could configure as much different trims to a channel as we like. (Of course we should allow more trim configurations then...)

After that we could simply add that trim value (from those of which have the same channel) on a mixer page, the switch of which is currently true. Since there could be more than one such, there should be a simple priority decision, like the order they are configured...

rbe2012 wrote: Or you will have a trim configuration which is based on switches which have nothing to do with the switches used for the mixer pages.

Exactly!
Just think about it: the value of that trim config should be applied, which the trim button clicks would change, i.e. we should use the same rule to select the trim value, independently of the mixer switches.
In fact it would work on a simple mixer too, which has only one page and no switch...

Any news/ideas about independent trims?

No news, but it is good that you bumped the conversation, as I was trying to figure out what other features to add, and was running low on ideas.

I've re-read through the entire discussion now, and here are my thoughts:

There are 2 different issues being raised in this thread:
1) how do we conditionally assign a trim based on a switch (and how do we know which trim to assign if the mixer switch != the trim switch)

2) should we abstract the real switches into virtual switch names to make it easier to do switch assignments (like on the standard gui)

For 1) my thought is to add a 'switch' column to the trim page, and on the mixer page you could choose the proper trim if more than one apply. I need to think more about FDR's concern about how this works for the simple and expo d/r templates though.

For 2) I'm conflicted. We could do a few things:
a) do it like the standard gui: Create a set of (possibly nameable) switches on a new page, and either make hese exclusively available, or additionally available (If we make them exlusive, we'd need to deal with converting models to use them automatically). This solution more or less ends up meaning you can rename your switches
b) use the virtual channels for this. Now you can define complex interactions for each 'switch', but setup is more cumbersome, since you need to do Virt1 = FMODE0, Virt2 = FMODE1, .... You can do this today, but to meet the stated goals, I think we'd need to allow renaming the virtual switches, and we'd probably need to add more of them.

I'm not sure how I feel on (2). I see the value of (2a) but I think it would be confusing to have 'FMODE0' and 'FM0' both available. if we replace FMODE0 with FM0, then you have the issue that you MUST have properly setup the switches ahead of time, which adds an additional barrier.

Right now, I think I'll start with solving (1). The issues aren't really related, and (2) is really just an optimization and brings no new functionality.

About 2a) - we can initially assign by default all virtual switches 1-to-1, ex. *RUDD DR = RUDD DR. Additionally, *FMODE virtual switch can has 2 options - common trims or independent trims.

And, replace at all selection lists all assigned switches by virtual switches.

Ok, I gave the independent trims some more thought. Here's my new plan:
The trim config page will get a new 'switch' control. this will behave like the toggle control, in that you specify 'FMODE' not 'FMODE0'. this will result in the trim having either 2 or 3 variables.
The mixer page will be unchanged, so you can only have one trim per source as today, and will be unable to select the trim to use for a given mixer. Since the trim value is precisely defined, the switches used on the mixer are irrelevant to which trim is used (so you can use one switch on the trim and a different one on the mixer.
The benefit of this solution is that it doesn't complicate the main page display. All of the other solutions I've thought of would require more configuration at the main page.

This should not be too complicated to implement, so I'll give it a shot and we can see how it works.

PhracturedBlue wrote: For 1) my thought is to add a 'switch' column to the trim page, and on the mixer page you could choose the proper trim if more than one apply. I need to think more about FDR's concern about how this works for the simple and expo d/r templates though.

I would avoid the need to select the trim to apply on the mixer pages.

If we can configure an optional switch to every trim config, then we can make 3 trim configs for the same input and trim buttons with exclusive switches (for example FMODE0, 1 and 2). Then the trim system would increment that trim config's value, the swich of which is true, and that same trim value would be added on those mixer pages, which have the same source whether they are complex mixer pages with the trim enabled, or simple or d/r mixers.

I wouldn't complicate it too much if there were more then one true switches, but would use the first...

I've just read your solution, and it will do fine too.
That will allow somewhat more limited options, but much easier to setup.

Ok, I've checked in the implementation I described above. It seems to work pretty well. Let me know if it doesn't meet your needs