Independent trims for flight modes

How I can get independent trim values for each flight mode?

Lost messages:

vlad_vy wrote: If you don't change plane geometry in time of fligh, it's right.

I'm trying to create a configuration for a full house glider with V-tail (6 channels), with 3 flight modes (Speed, Thermal and Launch), crow/butterfly braking and camber adjust. So I need independent elevator trimmer for each flight mode.

Even in original Devo 8 there are 'Flight Mode Trim Select' = 'Common' and 'Flight Mode'. In 'Flight Mode' each sticks trimmer is dependent from flight mode.

FDR wrote: You are right, this is the only feature of the original fw, which deviation don't have, basically because we don't have hard coded built-in flight modes...

I think you cannot even trick it, because each trim button only counts in one variable. The only way is to use different trim buttons of virtual channels for the different flight modes, and then add them in a complex mixer to the elevator channel...

vlad_vy wrote: It's surprise. I can without problems create complex configuration for full house glider, but i cann't create convenient independent trim for flight modes.

Maybe we need 'Flight Mode' setup, with at least 6 flight modes, flight mode names, switch selection, trim mode and so on.
Also will be nice to have ability to name virtual channels with complex mixers (V-Tail, etc.). And will be useful to create templates with the most commonly used mixers.

FDR wrote: IMO introducing built-in flight modes won't help much, but would make things even more complicated.

Now you can select on the complex mixer pages if you want to add trim to the current page based on the source, or not. If there would be more trim values for every source depending on some switches, you would have to select which one to use.

I don't know any relatively simple solution for this at the moment.
Give us some time to think about it...

rbe2012 wrote: I would at least support the proposal for renaming virtual channels.

We may think of 'Virtual Flight Mode' or 'Flight State'. 'Flight States' don't influence by any way to the Mixers. 'Flight State' is simply a data structure that may contain:

1. Name of 'Flight State'.
2. Switch that activate 'Flight State'.
3. Trims (at least Throttle, Elevator, Rudder, Aileron), i.e. pointers to memory locations of trims (choice from: current 'Flight State' trim or any other 'Flight State' trim).
4. Anything else specific for 'Flight State' (data, actions, ...) ???

Mixer will use these pointers as real (current) trims. 'Flight State 0' may be default and not contain configuration for switch and trims (for any switch and default trims), only name. If we don't need independent trims and other settings, we may leave 'Flight State 0' only.

It may be implemented as pages for complex Mixer. At first we will have only 'Flight State 0' (default). If needed we can add pages ('Flight State 1', ...).

rbe2012 wrote: I did a quick test. The normal trims influence the result of complex mixers, whatever number of pages are used. So I think the only way to achieve your goal would be to use virtual channels with different trims and glue them together in a complex mixer like:
vch1: throttle and fmode0 with trim A
vch2: throttle and fmode1 with trim B
...
channelX = complex ( vch1 and fmode0 | vch2 and fmode 1...)

I think it's the same and nothing need to change.

If thinking about trims only, maybe will be better link each trim (at trims page) to memory location by switch selection (Common (0) or FMode Sw (0, 1, 2)). At most we can get 3 independent trim values. It's better then nothing and will allow to have common or independent values for each trim.

Sorry, that I haven't came forward with a solution yet, but yesterday I was busy with the portal and today I had to work a lot...

So, don't rush!

What we do need here is a way for the trim setup to count the clicks of the same trim buttons into different variables depending some states, most probably switch states.

It won't hurt if we know, how things work now: Every trim setup row is a variable, to which we can configure which trim buttons clicks are added, and an input (more about it's name later), to which this value will be added on some mixer page. The simple and dr&expo mixer templates always apply the trim value appropriate for it's 'source', on a complex mixer page you can decide whether to apply it.

So the problems are:
1. While you can configure two trim setup rows (i.e. two trim variables) to the same trim buttons, but then their values always would be the same.
To resolve this we need to add an optional 'switch' to each trim setup line. This way that trim value only incremented/decremented if the switch is true.

2. Which trim value to add on the mixer page?
You could say there should be a selection on the complex mixer page. However don't forget about the simple mixer, and the fact, that it should be simple!
So my suggestion is to keep things simple: There would be only the current 'trim'/'no trim' selection, and if there is more then one trim values are configured to the particular source, we would add that one, of which the switch is true.

3. So here comes the last problem: there could me more then one trim value with true switch value for a source.
This can be solved a few ways, for example some simple fixed priority or by the defined order, etc.

So this would work without defining any flight states. I don't say they wouldn't be useful for other purposes, but aren't neccesary just for this...

Some thoughts about the 'flight modes' or 'flight states':

I like the idea, but not that way.
I would simple make it as an assignment for real switches, aka define in c.

This way the model configs and especially the templates could be more generic, because I could use these 'flight states' as switches, and if somebody else want to use my config or template, but doesn't like my switch choices, he could simply change the flight state assignments to the switches he prefers.

If they would be custom named or just simply numbered (like FM1, FM2, etc) is no matter (at least for me).
However custom names should be unique, and shouln't use existing switch names...

Actually (while it's a bit off topic here), I could imagine such an assignment for the channels/sticks too.
It would ease creating generic templates...

deleted

No it's simpler than that, so here is some explanation:

How do we configure flight modes now?
They are used mostly in throttle and pitch curves, and perhaps in the gyro settings.
You can use an 'Expo&DR' or a 'Complex' mixer template to configure different curves/functions for the different flight mode switch values, most likely you will use the FMODE0, FMODE1 and FMODE2 switch values.

However if somebody would like to use your config, but want to use the MIX switch values (MIX0, MIX1, MIX2) to differentiate the flight modes, he would have to change all the selected switches, which can be quite a lot.

But if we could assign these switch values first to some 'virtual' switches, and use those in the model config everywhere, then the aforementioned switch change would be only a few clicks, and the whole config would be more readable...