Closed bsongis-frsky closed 1 year ago
X20
+ Ethos 1.0.10
Type of issue : Enhancement
Here is a proposal I submitted a few months ago on the GitHub of ETHOS-TEST. At that time, the urgency was not to make this type of development, and it was normal !
This is a constructive proposal to improve ETHOS. Please don't consider this post as a misplaced criticism : the work of the ETHOS developers is really impressive (and I imagine very time consuming) ! I also understand that there are priorities on the developments to be done and marketing imperatives.
Trim
in ETHOS/OpenTxTrims
and GV
► B1 - Special parameters
UI
► B2 - The Objectives
► B3 - Using the Special parameters
UI
> Scenario 1: Setting the step of a trim
> Scenario 2: Setting an independent trim for 3 flight modes
> Scenario 3: Setting an independent Trim' only for
FM2
> Scenario 4: Setting a Trim
using independency, equality and dynamic offset
> Scénario 5 : Setting up a GV
► B4 - UI details
> B41 - Main display of Specific Parameters
With the integration of the new Edge
condition (https://github.com/FrSkyRC/ETHOS-TEST/issues/163), the Ethos engine will be powerful enough to be able to do the same operations that can be done with global variables (GV) in OpenTx. We can then reproduce (with the Edge
=╂
condition) :
OpenTx | ETHOS |
---|---|
N1► SF1 - If SA↓ then AdjustVG1 with Value=1 | N1► GV1:=Source{Max} If{╂ SA↓} Weight{1} |
N2► SF1 - If SA↓ then AdjustVG1 with Source = Pot | N2► GV1:=Source{Pot} If{SA↓} Weight{100} |
N3► SF1 - If SA↓ then AdjustVG1 with Source = Trim | N3► GV1:=Source{Trim} If{SA↓} Weight{100} |
N4► SF1 - If SA↓ then AdjustVG1 with Increment = 3 | N4► GV1+=Source{Max} If{╂ SA↓} Weight{3} |
N5► SF1 - If SA↓ then AdjustVG1 with VG4 | N5► GV1:=Source{GV4} If{╂ SA↓} Weight{100} |
Output
with the Mini/Maxi of the channel representing the GV.Trim
in ETHOS/OpenTxTrim has a scale (extended or normal), is set to a value, or is adjusted using a physical source (most often the physical Trim, but not all the time).
Finally, what if the Trim
was nothing more than a particular global variable?
To prove this, in issue https://github.com/FrSkyRC/ETHOS-TEST/issues/180 I used the ETHOS engine to reproduce the behavior of OpenTx trims. So I showed that the ETHOS engine, with the ╂
condition, allows to reproduce the following behaviors:
Trim
identical regardless of the flight phases Trim
according to each phase of flightTrim
value between two flight phases If you looked at the document in https://github.com/FrSkyRC/ETHOS-TEST/issues/180, writing all the necessary mixers is very very indigestible. To handle trims like this, the mixers need to remain hidden from the user.
However, the ability to write the Trim
functionality with the existing ETHOS engine has 2 advantages :
Trim
Trim
can be manipulated as global variables and this allows to have much better functionalities than OpenTxFeature | OpenTx | ETHOS |
---|---|---|
Trims equality relationship between two selected FM states | Yes | Partial (Trim is equal for all flight phases) |
Trims offset relationship between two selected FM states | Yes | No |
Trims independence for one or more selected FM states | Yes | Partial (Trim is independent for all flight phases) |
Disconnection of the usual physical source of the Trim for one or more selected states of FM (=Unplugging physical source) | Yes | No |
The OpenTx UI regarding the management of trims is very ugly and makes it difficult to understand. It is a simple two-dimensional table with a particular code (to be deciphered)
In OpenTx, the trim settings are made:
Model setting
for the Step
and Extended trim
.FM
for the behavior
.In OpenTx, the GV
settings are done :
FM
to initialize them (min, max, value according to FM)So there are 3 different places to handle Trim
and GV
with OpenTx. This is already 2 too many !
As well for the Trims as for the VG, the UI proposed by OpenTx are ugly (simple two-dimensional tables).
GV
can quickly become unwieldy in ETHOSTrims
and GV
For ETHOS, I propose to create a single UI common to Trim
and GV
Special parameters
UIAs in ETHOS, the global variables are not necessarily related to a flight mode, the UI does not have to be in the same place as the flight phases. As in ETHOS, the trims are nothing else than particular global variables, they find their place in this UI. These parameters, considered by the user as special, are grouped together in the same place and under a user-friendly interface.
Trim
and on GV
)Basic
, Advanced
, Expert
, Compatiblity mode
, ... so no differentiated UITrims
and GV
settingsSpecial parameters
UIBefore presenting the UI in a general way, I prefer to show some usage scenarios.
SP
means Special Parameter
.Starting situation:
FM
other than the default oneExtended trim
option, to see its effect.■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 1 in HD defintion ■
Starting situation:
FM0
, FM1
, FM2
Elevator TRIM
independently for each of the FM
■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 2 in HD defintion ■
Trim
only for FM2
Starting situation:
FM0
, FM1
, FM2
Elevator TRIM
independently only for FM2
■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 3 in HD defintion ■
Trim
using independency, equality, dynamic offset and unplugged operationStarting situation:
FM0
, FM1
, FM2
, FM3
, FM4
Elevator TRIM
independently for each of the FM
Elevator Trim
between FM0
and FM1
► have a +6 dynamic offset of my Elevator Trim
between FM0
and FM3
► have my independent Elevator Trim
for FM2
► disconnect the usual physical source of Elevator Trim
for FM4
■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 4 in HD defintion ■
GV
Starting situation:
FM0
, FM1
, FM2
Ele_compensation
with a scale from -20 to 60. This is a variable that has no usual physical source.Ele_compensation
to +40.Otherwise
my value remains unchanged
► when I have FM1 AND SI↑
I add +10 to my current value
► when I have FM1 AND SF↓
I set my value to -5
► when I have FM0
my value is set with Elevator TRIM
value (with scale adaptation)
► when I have FM2 AND SJ↑
my value is adjusted by the selection wheel■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 5 in HD defintion ■
■ VIEW ALL SCENARIO : Playlist with all scenario
This UI is just after Special functions
.
I have taken the principles I proposed in https://github.com/FrSkyRC/ETHOS-TEST/issues/129 (Improvements proposal for LSW), i.e. :
link
button and allows editing. The user sees the result of his input in real time with a syntax highlighting.Specific Parameters
Here is the main display of Specific Parameters
ou SP:
I have chosen to make two pages:
Here is the first page for a TRIM :
Here is the first page for a GV :
Usual source
and to reverse the trim operation allows the user of boats, cars, and other devices to customize the operation of the trims. You can even cross or reverse trims with this management. The purpose of this page is to give a visual and graphical overview of the behavior of a trim or a VG according to a given state.
Here is the second page for a TRIM :
Here is the second page for a GV :
When
conditionsWhen
conditions. However, the Otherwise
condition present by default cannot be deleted . It allows you to assign a value to the VG when you first edit it.Otherwise
condition for a VG is the FM0
condition for a Trim.When we switch to the edition of one state (one line) we obtain:
The possible operations are :
Some comments:
Equal
and Offset
operationsEqual
and Offset
operations will be available only for Trim When
is a condition which has 1 or 2 arguments. Why two arguments ? Because the practice on OpenTx showed me that you have to do an LSW of an AND with two arguments before reusing it in a special function. This possibility allows to lighten the global writing of a program.Specific parameter
into a mixer group (the opposite is not possible)Equal
and Offset
operations for the GV (to think about to know the possible interactions)Thanks for reading !
Feel free to comment this proposal...
I do like this proposal, but I have some minor comments:
1) I would not mix Trims and GVars. I find it is not very intuitive for the user who just wants to change the Trims scale to enter into this screen!
2) I would not keep the Trim name
3) I would not keep the "default source" for GVars
In my opinion, the management engine and the operating principles of the trims/Gvars will be almost identical.
I agree with bsongis on every count. Global variables can be used in so many different ways that it would be very confusing to tie them in any way to trims. They should have their own menu selection in the 'Model' section.
I'd love to see this issue assigned a milestone again.
The lack of GVAR and the lack of a PC app are the two issues holding me back from buying an X20 and getting into EthOS.
and if we have GVARS again, We need a counter-function at special functions like #759 Counter at special function up, down, steps, set, reset, autopreset, ringcounter
Being able to separate the value of a GVAR per flight mode and the process of changing that value is important. OpenTX permits the adjustment of a GVAR in special functions and that action works on a priority basis.
Trims: referring to Celestin's paragraph A22, we need to have all the features of OTX which are in his table replicated in Ethos. This is essential for advanced sailplanes.
GV's: In OpenTX, a trim lever can be repurposed in real time - and transparently - to update a GV instead of the parent trim. This is incredibly useful for features like SuperTrim. This is not possible in Ethos, and until then, my Ethos templates will lag behind OTX in a key area.
In short, in order for Ethos to be the preferred OS for gliders, it needs all the features which are currently available in OpenTX for both trims and GVs.
One way of describing basic need: An indexed global variable (i.e. GV1(FM2) ) value that can be changed by a selecting (pushing trim, to moving switch) a non-analog trim or switch. OpenTX does this with Special Functions.
@bsongis-frsky What's the progress on this? I see it keeps moving to future milestones, so I was wondering if you had a rough idea of when you expect it to be released?
This would be awesome long-term addition. I would love to see this alongside VAR mixes.
In the short term, I'd just like to see Special Function based adjustment of current VAR mixer value, to get VAR mixers to be a full replacement for OTX GVAR functionality.
I've come so close to trashing my X20S and it's inferior Ethos system and now I see that the Global Vars milestone has been pushed back again. I was lead to believe that Ethos could do everything OpenTX was capable of and much more, rushed out and purchased the Tandem X20S and many receivers for it having all intensions of using the system for competition gliders and iNav setups and yet here we are two years later and have still not used my X20S because of the lack of OTX GVAR functionality and the use of GV's in special functions.
Have been waiting for GVAR and a companion program before any purchase. Like you, close to giving up...
Those are the deal breakers for me too, the latter especially.
The longer the features are omitted, the more I start to feel that EthOS and my use case are on divergent paths.
@RC-SOAR Would you please review this proposal for 1.5.0? I write an example for a Differencial Var which can take 3 values and has actions to increase / decrease those 3 values on an event:
Name "Differential"
Values
- Default 30%
- FM2 40%
- FM3 50%
Actions
- T5-Up Add(+) +2%
- T5-Down Add(+) -2%
Output CH16
I think this proposal brings all features from OpenTX, but without limitations like:
And actions will be shown on the same screen than the values.
@bsongis-frsky Thanks, Bertrand - could you provide a little more info, please?
Some preliminary comments:
Would this proposal work for your use case?
And this is the screenshot for a scenario where you need more than one value for your Var Mix, depending on the Flight Mode condition.
Would this proposal work for your use case?
I think your proposal might work for the use case I quoted. However it depends on the behaviour of the trim, and I'm still not 100% clear how it works. Could you explain the three points below? In the second screenshot:
If the answer is Yes to all three, then I believe my use case would work.
The key is to allow the elevator trim behaviour to be either system default or update a channel , depending on an active condition.
Another Use Case A way to have the Actions active or in-active. Example: Rudder trim is on LH{L,R) Also want to use LH(L,R) for adjusting a VAR for rudder comp with a switch to enable the action and that overrides the Rudder Trim action. Similar to using an OpenTX Special Function to modify a GVAR.
Name "Rudder Comp" Values
@RC-SOAR
All values of a Var Mix are persistent. Even in 1.4.x
For the 2 first questions, the answer is Yes. This screenshot will make it obvious.
@fhpage Here is the screenshot for your use case
YES! Another use in sailplanes(and probably the most common) is for elevator compensation, whether it is for flaps or motor. Example: Flight modes: Launch, Cruise, Speed, Thermal, etc. Want to use cross trim (Throttle trim or LHL,R) for general trim of elevator in Cruise mode. In other modes want to use Throttle trim to adjust elevator compensation with flap position which is added to elevator position that was set in cruise mode. I believe your examples above satisfy this situation!
If you had multiple var mixes repurposing the same Trim, who wins? Could you do either the first or the last mix wins(pre-empts the others)?
The last order to repurpose a trim will win. It means that if two different VarMix (or one VarMix with two actions) have an active action which repurposes the same trim, the last one will win.
Any chance we could test this in a pre-release version?
Any chance we could test this in a pre-release version?
or in a Simulator version on PC.
Change and store a value at a VAR mixer
Clipping at a Range
Source Trims, Steps and Analog
I'd also be happy to know when this becomes available. I've bought x20s and have all models to reprogram (from opentx). If global vars come in next month, I'd wait with this work until they come.
One more thing - I wondered why var mixers don't support this:
Could it be fixed in new version? It seems to be missing for me and a useful function, for example to switch between different rates smoothly.
VAR mixers are value selectors, they don't mix in the same way other mixers do, they just output the currently active value. In this they are like GVAR's. This has implications elsewhere as well (don't mix VAR and non-VAR mixers on the same channel)
You can use Flight Modes or a proxy Free Mix to add slow for smooth transitions.
VAR mixers are value selectors, they don't mix in the same way other mixers do, they just output the currently active value. In this they are like GVAR's. This has implications elsewhere as well (don't mix VAR and non-VAR mixers on the same channel)
You can use Flight Modes or a proxy Free Mix to add slow for smooth transitions.
How to solve the following problem then:
I imagine, currently (1.4.6) the way to do this would be:
Which is ok, but a bit long way. Is there any better way?
If we get GVARs, then the solution probably will be:
Which works, but I thought we wanted GVAR to get rid of using extra channels.
I mean, for me this would be nice to have. It can be workarounded, and OpenTX didn't have anything like this either. "Nice to have" feature really.
Maybe another solution would be to allow using "mixers" as sources, without assigning them to any channel. Then having such "proxy" mixers, to manipulate values, would feel much more natural.
You see, for me the whole concept of "outputting something to a channel, to use it as a source for something else" is not really in spirit of all great changes done in Ethos in comparison to OpenTX. It's the only place in Ethos where I need to think OpenTX way "which slot (here: channel) do I use for this thing, so I can maybe have similar functions in nearby slots together, and have same thing in same slots in other models, which hopefully they have free, not to produce mess, because it's impossible to reorder these things later".
I really love how in other places (LS, SF, timers, curves...) in Ethos you don't have those "slots". You just have as many entries as you need, and can reorder them. This is so great.
VAR mixers are value selectors, they don't mix in the same way other mixers do, they just output the currently active value. In this they are like GVAR's. This has implications elsewhere as well (don't mix VAR and non-VAR mixers on the same channel) You can use Flight Modes or a proxy Free Mix to add slow for smooth transitions.
How to solve the following problem then:
- have a "dual rate" switch, which switches between different values of "weight" and "expo"
- have it independent of flight mode
- I assume both "rate" and "expo" would be a VAR/GVAR, to be easy to use and defined in one place
- have smooth transition over some period of time between different values of a GVAR
- both things are to be used here:
I imagine, currently (1.4.6) the way to do this would be:
- have a VAR with all values of expo, outputting to channel A
- have a free mix, which uses channel A as input, and produces channel B
- use channel B as source for expo in you aileron or elevator or rudder
Which is ok, but a bit long way. Is there any better way?
If we get GVARs, then the solution probably will be:
- have a GVAR which defines your values (no need to output it to any channel)
- have a "proxy" free-mix which uses the GVAR and produces channel A (just to have slowdown)
- use channel A as a source for your expo wherever needed
Which works, but I thought we wanted GVAR to get rid of using extra channels.
I mean, for me this would be nice to have. It can be workarounded, and OpenTX didn't have anything like this either. "Nice to have" feature really.
Maybe another solution would be to allow using "mixers" as sources, without assigning them to any channel. Then having such "proxy" mixers, to manipulate values, would feel much more natural.
You see, for me the whole concept of "outputting something to a channel, to use it as a source for something else" is not really in spirit of all great changes done in Ethos in comparison to OpenTX. It's the only place in Ethos where I need to think OpenTX way "which slot (here: channel) do I use for this thing, so I can maybe have similar functions in nearby slots together, and have same thing in same slots in other models, which hopefully they have free, not to produce mess, because it's impossible to reorder these things later".
I really love how in other places (LS, SF, timers, curves...) in Ethos you don't have those "slots". You just have as many entries as you need, and can reorder them. This is so great.
No need for VAR's to do this. ETHOS - Free Mix with Custom (expo) curves. They have expo % plus limit %. Can do the same if define the program to be Airplane or Glider. Best to post in RCGroups for a comprehensive solution.
@azaz44 - GVAR's are not about getting rid of extra channels or channel usage, rather ETHOS moves closer to the pure 'everything is a mix' concept compared to OpenTX, having rolled Inputs, CCPM and GVAR's into the mixers rather than having separate pages/functions for them. In addition ETHOS moves away from Special Functions, making them really the Audio function page aside from a couple items that really don't have anywhere else logical and were Special Functions in OpenTX.
Your two proposed solutions are in fact absolutely identical. There's no difference aside from the way you call the input, and the change actually will make the UI more complex (you need another category for every mixer output defined in addition to the collective mixer stack). So more complexity, but no gain for VAR usage. There are limited cases where being able to directly call a mixer output rather than a mixer stack output might be valuable, but this is very definitely not one of them.
Note the Mixer page allows re-ordering just like the other core pages (Flight Modes, Special Functions. Logical Switches) with the same priority stack function of the order. You can change the view to per-channel view, but I only do that when I'm debugging a single channel and need to see the mixer stack on that specific channel.
Mixer Channels are really just arbitrary sets of mixer output stacks, matched 1:1 to Output channels for simplicity. Separating that alignment might make things a bit more powerful, but would greatly confuse the issue for less technically inclined users. As it is ETHOS has largely eliminated one of the primary confusions for less technical users (mixers not present when inputs are configured) and you largely don't have to interact with the mixer stacks beyond selecting arbitrary ones for your non-RF channel assigned mixer stacks.
Personally I stick with meaningful names for everything and assign RF-linked mixer stacks starting with Ch1 and incrementing, and non-RF linked stacks starting with Ch64 and decrementing. It's rare that I need to bother looking at the mixer stacks/mixer channels except when I'm connecting sources to outputs. When doing most of the programming it's the regular Mixer UI, which as I note, functions exactly like the other UI's you are asking for it to function like (LSW, SF, FM, etc). Note that aside form Curves, each of those use order to manage priority. Curves are single instance items with no concept of priority of course.
No need for VAR's to do this. ETHOS - Free Mix with Custom (expo) curves. They have expo % plus limit %. Can do the same if define the program to be Airplane or Glider. Best to post in RCGroups for a comprehensive solution.
It's not need or not need for me. One reason, and a big one, to use VARs for me is to define fixed values in a convenient place where they can be found and edited easily. So if you want to change cyclic expo (in case of a helicopter), you go to a VAR called "Cyclic Expo" and have all cyclic expo values there, for all modes. And not look in individual mixes. if I understood you correctly.
@mawzthefinn I have to say I might not be getting everything you wrote. One good thing is that I wasn't aware there is any priority related to for LSW or SF, so now I know. But how does it change things? I thought in OpenTX everything was evaluated (for example in LS) based on previous cycle. Thus order of evaluating LSes would not make any difference. Is it different in Ethos?
As for mixes, let me show you how I organize them. Then I can tell you what I find problematic with it. And you can tell me how I could do things better :)
So I have 3 groups:
Probably I would need to add another group at some point:
To recap previous post again, one big function of VAR here is
Happy to hear what could I do better here, or if I'm abusing the system in some ways. I maybe got things wrong here.
As for what I see a bit problematic, in the way I used it, is:
Sorry for long description. Let me also say at the end, that I find Ethos really really good with many improvements over OpenTX. This nitpicking above is about this last 5% so it would be perfect, and of course, at the end things don't have to be perfect, they have to work. So great job there guys.
Yes, both SF's and LSW's are processed in order, top to bottom. It's VERY relevant for special functions (as it allows you to string together multiple audio callouts in order) but is only relevant to LSW's in certain edge cases, where one firing before the next is processed can be an issue (I noted this when troubleshooting initialization behaviour for LSW's)
I see you do a lot more with values and a lot less with mixer chains than I'm generally familiar with. Take a look at some of the ETHOS templates on RC-Soar.com for some good examples of the sort of mixer chaining that I (and others) use.
Different screens is not what I currently expect for VAR's, at least medium term. If we get the more advanced VAR implementation proposed in the future that would be a separate interface I would expect.
You're really over-thinking this I think. How many values are you using? I'm seeing WAY more than I'd use for a very advanced sailplane setup (as an example). If you do not need switchable values, put them in the mix itself, it's only if you need multiple selectable values or one value shared in multiple spots where you need to do values on separate channels. And I'm curious why you use the same model definition for both SIM and the actual aircraft? I have SIM-specific models because they need different setup.
Output setup has no effect on anything except the conversion to channels actually sent over RF. The mixer channel values are what is used for channels as sources. Like OpenTX, ETHOS actually supports all channels over RF, it's only the channel range sent to the module that limits you (you can currently get 40 channels over RF if you really want to, with 24ch on internal running in 2.4G ACCESS and 16 channels on external R9 modules)
Yes, both SF's and LSW's are processed in order, top to bottom. It's VERY relevant for special functions (as it allows you to string together multiple audio callouts in order) but is only relevant to LSW's in certain edge cases, where one firing before the next is processed can be an issue (I noted this when troubleshooting initialization behaviour for LSW's)
Good to know this, thx 👍
I see you do a lot more with values and a lot less with mixer chains than I'm generally familiar with. Take a look at some of the ETHOS templates on RC-Soar.com for some good examples of the sort of mixer chaining that I (and others) use.
- Different screens is not what I currently expect for VAR's, at least medium term. If we get the more advanced VAR implementation proposed in the future that would be a separate interface I would expect.
OK. I also understand that Ethos tries to be more "easy" so we will get some compromises between power and easiness, and I also understand you might have more urgent problems to solve than this one. No problem with that.
- You're really over-thinking this I think. How many values are you using? I'm seeing WAY more than I'd use for a very advanced sailplane setup (as an example). If you do not need switchable values, put them in the mix itself, it's only if you need multiple selectable values or one value shared in multiple spots where you need to do values on separate channels.
I think I don't have that many. I actually fly only helicopters, which are - I thought - easier that many planes or gliders when it comes to programming. My "numbers" are:
Plus I will have a couple of parameters which end up in RF channels, because flight controller (FBL) needs them, like
And yes, until this year, some of them I would keep at the same value always (rate, expo, pitch settings). Although I would still love to have the "numbers" (which I tune every some time) separated from "rules" (mixer logic). (OK, I might be expecting too much...)
But this year I started with F3C (precision flying), and in F3C all of these numbers actually need different values for different flight modes. Especially "hover" mode is so different than other "flying" modes, that all of these params need different values.
Advaned F3C guys also change these numbers per maneuver they just make, so they tend to use all the switches they have to trigger some different values, independent of fligh modes. But I don't do this (yet..).
And I'm curious why you use the same model definition for both SIM and the actual aircraft? I have SIM-specific models because they need different setup.
Oh no, I don't do this. I have "SIM" model in my radio (with XSR-SIM bound to it) and never mix it with real models. I maybe didn't explain sth clearly.
The description about SIM was probably related to my channels 63 and 64 which I use to control LCD backlight. In System settings, you can use a "source" for LCD backlight levels. Example from the X18 simulator:
And I use it. Binding this to "channels" allows to make LCD backlight levels different "per model". Not sure if this was planned by Ethos developers. Probably not, probably the idea behind an option to use "source" for LCD backlight was just to allow to control it with some slider. But having them bound to channels, and thus control values "per model" is great, because
It's only briefly related to VARs problem. But I describe this so you know how users are abusing Ethos :)
- Output setup has no effect on anything except the conversion to channels actually sent over RF. The mixer channel values are what is used for channels as sources. Like OpenTX, ETHOS actually supports all channels over RF, it's only the channel range sent to the module that limits you (you can currently get 40 channels over RF if you really want to, with 24ch on internal running in 2.4G ACCESS and 16 channels on external R9 modules)
This is good to know.
That's quite interesting overall:
For the following values, I have some comments:
cyclic (elevator and aileron) rate - VAR mix makes sense here since it's a shared value cyclic expo - here as well, same reason rudder rate - You should be able to do multiple rates fine in the mixer, why have a VAR for it? rudder expo - You should be able to do multiple expos fine in the mixer, why have a VAR for it? - note though that IIRC you are limited to 3 expo's in the mixer, if you need more settings, then the VAR makes sense pitch weight - You should be able to do multiple rates fine in the mixer, why have a VAR for it? pitch offset - This one I think you do need a VAR for, I don't recall multiple offsets being supported otherwise. pitch expo - You should be able to do multiple expos fine in the mixer, why have a VAR for it? - note though that IIRC you are limited to 3 expo's in the mixer, if you need more settings, then the VAR makes sense throttle (we use fixed throttle values in most helis, and governor makes sense out of them and makes the headspeed run at some RPM) - Different curves are the normal solution here.
Regarding screen brightness, when at the field I normally only want the backlight on when changing models or adjusting programming, when flying I use callouts for anything I need to reference so the backlight can remain off on the screen when flying.
Interesting, I didn't realize I could make multiple expos directly in the mixer. This is useful for me, thx. I mean I saw multiple curves there, and though - wow that's great, I needed this once in OpenTX and could not find a solution (I needed to combine "Expo" with "deadband", deadband made in a custom curve because it wasn't there by default). But I missed that they can be controlled by switches. I thought they just get all applied together always. Cool feature.
As for weight, how would you have multiple weights? One solution that comes to my mind, is make initial mixer with 100%, and then add VAR mixer after that... no, I think VAR does not support "multiply". So how to do this? Of course without having multiple mixer lines.
But in general, as for "why have VAR for it". It's not only to reuse it. It's also to extract it from mixer logic. I wonder how to explain it better. I look at it like this:
I judge from your description that this was not what VARs were really meant to be - ok. Although I think this is very useful for that (maybe in future). And then it makes sense to have these in different screens.
As for RPM -> no need for curves here, this is just flat value. 50% in FM0, 60% in FM1, 70% in FM2 or sth like that. At least in bigger helis.
As for LCD backlight, I only use LCD sometimes during flying, when tracing problems. Or after landing, to see if I have battery for another autorotation. But I always wanted to have the screen at the top because of these situation, and love it in C20 and X18.
You should be seeing the option to add weights on your standard mixers (you are using standard mixers, not Free Mixes, for your cyclic & pitch, right?). I just checked and the Pitch control does require use of a VAR mix for weights but the Aleron & Elevator mixers allow multiple weights.
Your separation does make sense for all Free Mix approach to programming, but it's quite different from the regular use cases where standard mixers are used for most functions and defined within and which is the primary focus
As to RPM, the reason to use Curves is largely because that allows use of the standard Throttle mixer (which has timer integration as well as hold/cut/trim built in). 2-point curves are the current answer to fixed RPM (although single-point has been asked for to address this use case)
You should be seeing the option to add weights on your standard mixers (you are using standard mixers, not Free Mixes, for your cyclic & pitch, right?). I just checked and the Pitch control does require use of a VAR mix for weights but the Aleron & Elevator mixers allow multiple weights.
Your separation does make sense for all Free Mix approach to programming, but it's quite different from the regular use cases where standard mixers are used for most functions and defined within and which is the primary focus
As to RPM, the reason to use Curves is largely because that allows use of the standard Throttle mixer (which has timer integration as well as hold/cut/trim built in). 2-point curves are the current answer to fixed RPM (although single-point has been asked for to address this use case)
Hmm, I use Free-Mix for everything. I though "Free Mix" has all the options, and other types are just less advanced, to make things easier. But I see I was wrong. Let me test this..
This feature will be in the next nightlies!
@azaz44 - Free Mixes are the do-everything mix, the specialty mixes are in some ways more powerful, but also more limited to their specific application. Not all options are necessarily available in Free mixes, but anything can be done with them, it just might require more than one Free mix to duplicate a single specialty mix.,
@mawzthefinn
@azaz44 - Free Mixes are the do-everything mix, the specialty mixes are in some ways more powerful, but also more limited to their specific application. Not all options are necessarily available in Free mixes, but anything can be done with them, it just might require more than one Free mix to duplicate a single specialty mix.,
Yeah I see that clear now. Maybe with free mixes you need more lines sometimes to do same thing as a "predefined" mix does. I'll probably stay with using free mixes, as I don't want to hit the brick anytime in future. I use very untypical setups sometimes, and my radio is heavily tuned as it comes to hardware. I need max flexibility.
Also, in my case I mainly play with the model for "simulator" as of now, and because I set it as "Other" (as in sim you can fly helis, planes, whatever), I don't have these predefined mixes available. All my physical models wait yet to be programmed, but I have still quite some time to do this (winter here), thus I delay it until I convert all my required OpenTX luas to Ethos maybe Ethos gets update sin between which change how I program.
Thx for a lot of clarifications.
@bsongis-frsky I can't wait to test this 👍
@bsongis-frsky Simulators are not there, will they come too?
Unfortunately I've not had a chance to install the nightly in order to check out the new feature - hopefully today or tomorrow.
@bsongis-frsky Will there be new nightly for X10S?
If we use a switch or a button to inc/dec a value , it inc / dec way too fast. Please make the Interval adjustable.
what we need for this switch or Button inc, dec, with steps and repeating time autoset and autoreset Range with Clipping
Range is already there, for the VAR mix.
Set is a separate action.
I agree that repeat time needs to be configurable, or work like a standard trimmer
They are needed