search

FrSkyRC / ETHOS-Feedback-Community

Feedback & suggestions are welcomed here for ETHOS by FrSky
180 stars 83 forks source link

Global Vars #779

Closed bsongis-frsky closed 1 year ago

bsongis-frsky commented 2 years ago

They are needed

Ceeb182 commented 2 years 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.

A - Comments and observations on the initial situation

A1 - Current handling of global variables in ETHOS/OpenTx

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}

A2 - About Trim in ETHOS/OpenTx

A21 - Trims can be seen as particular global variables in ETHOS

Trim 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:

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 :

A22 - ETHOS/OpenTx comparison about trims

Feature 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)

A3 - About the OpenTx UI for Trims and GVs :

In OpenTx, the trim settings are made:

In OpenTx, the GV settings are done :

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).

A4 - Synthesis of observations

B - Proposal: create a single GUI common to both Trims and GV

For ETHOS, I propose to create a single UI common to Trim and GV

B1 - Special parameters UI

As 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.

B2 - The Objectives

B3 - Using the Special parameters UI

Before presenting the UI in a general way, I prefer to show some usage scenarios.

In all that follows SP means Special Parameter.

► Scenario 1: Setting the step of a trim

Starting situation:

■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 1 in HD defintion ■ Scenario 1: Setting the step of a trim

► Scenario 2: Setting an independent trim for 3 flight modes

Starting situation:

■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 2 in HD defintion ■ Scenario 2: Setting an independent trim for 3 flight modes

► Scenario 3: Setting an independent Trim only for FM2

Starting situation:

■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 3 in HD defintion ■ Scenario 3: Setting an independent `Trim` only for `FM2

► Scenario 4: Setting a Trim using independency, equality, dynamic offset and unplugged operation

Starting situation:

■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 4 in HD defintion ■ Scenario 4: Setting a `Trim` using independency, equality, dynamic offset and unplugged operation

► Scenario 5 : Setting up a GV

Starting situation:

■ As GIF files cannot be viewed in full on GitHub, you can view the entire animation on Youtube : Scenario 5 in HD defintion ■ Scenario 5 : Setting up a `GV`

■ VIEW ALL SCENARIO : Playlist with all scenario

B4 - UI details

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. :

► B41 - Main display of Specific Parameters

Here is the main display of Specific Parameters ou SP: SP Main display

► B42 - Editor pages (2 pages)

I have chosen to make two pages:

>> Page 1 : General definition of the special parameter

Here is the first page for a TRIM : SP Page 1 for SP:Trim

Here is the first page for a GV : SP Page 1 for SP:GVar

>> Page 2 : Custom behavior of the special parameter

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 : SP Page 2 for SP:Trim

Here is the second page for a GV : SP Page 2 for SP:GVar

When we switch to the edition of one state (one line) we obtain: SP State - Edition screen

The possible operations are :

Operations available for SP

Some comments:

C - Other proposed improvements for future releases

Thanks for reading !

Feel free to comment this proposal...

bsongis-frsky commented 2 years ago

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

Ceeb182 commented 2 years ago
  1. Ok not to mix Trim and Gvar. I totally understand that a user wants to find quickly and directly the trims in the ETHOS interface. This is totally justified.
  2. I don't agree. It should be possible to change the names of the trims, especially for naval, land and space modelling, as well as for other atypical uses.
  3. Ok to remove "default source" for Gvars because there are other possibilities to connect a Gvar momentarily to a source.

In my opinion, the management engine and the operating principles of the trims/Gvars will be almost identical.

dwheeld commented 2 years ago

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.

VancouverUmbrella commented 2 years ago

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.

hrenz commented 2 years ago

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

fhpage commented 2 years ago

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.

RC-SOAR commented 2 years ago

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.

fhpage commented 2 years ago

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.

petermumford commented 1 year ago

@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?

mawzthefinn commented 1 year ago

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.

jamesn1960 commented 1 year ago

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.

fhpage commented 1 year ago

Have been waiting for GVAR and a companion program before any purchase. Like you, close to giving up...

VancouverUmbrella commented 1 year ago

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.

bsongis-frsky commented 1 year ago

@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.

RC-SOAR commented 1 year ago

@bsongis-frsky Thanks, Bertrand - could you provide a little more info, please?

Some preliminary comments:

bsongis-frsky commented 1 year ago

Would this proposal work for your use case?

image

bsongis-frsky commented 1 year ago

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.

image

RC-SOAR commented 1 year ago

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.

fhpage commented 1 year ago

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

bsongis-frsky commented 1 year ago

@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.

image

bsongis-frsky commented 1 year ago

@fhpage Here is the screenshot for your use case

image

fhpage commented 1 year ago

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)?

bsongis-frsky commented 1 year ago

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.

RC-SOAR commented 1 year ago

Any chance we could test this in a pre-release version?

loetefix commented 1 year ago

Any chance we could test this in a pre-release version?

or in a Simulator version on PC.

hrenz commented 1 year ago

Change and store a value at a VAR mixer

Clipping at a Range

Source Trims, Steps and Analog

azaz44 commented 1 year ago

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.

azaz44 commented 1 year ago

One more thing - I wondered why var mixers don't support this:

image

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.

mawzthefinn commented 1 year ago

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.

azaz44 commented 1 year ago

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:

image

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.

fhpage commented 1 year ago

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:

image

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.

mawzthefinn commented 1 year ago

@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.

azaz44 commented 1 year ago

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.

azaz44 commented 1 year ago

@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 :)

image

So I have 3 groups:

  1. from 64 going down --> global radio settings. In this case I have values for LCD brightness, because I want to have control over LCD "per model" (different settings for flying simulator indoor, different for real models outdoor, keeping screen always on when in air, keeping it mostly off when in SIM etc.). Sound volume will go to this group too. I then use these channels as sources in radio settings -> LCD, Volume.
  2. VARs starting from 33 going up. These are all important "numbers", which I tune more often than not, so they are placed at the top. As I wrote before, one reason to use VARs for me is to group these values in convenient place. Kind of like "CONST" section in software programming. Or "Definitions". Or "Given" in math. I don't know how to explain it better, but I hope you know what I mean.
  3. Then all mixers follow. This is "mixer logic" which decides how model behaves, and which I don't need to touch if model is programmed correctly (in software programming this would be "real code doing stuff") image

Probably I would need to add another group at some point:

  1. "Intermediate values" - so for example mixer, which allows you to add "slow down", like I described above. It is also "mixer logic", which you rather setup once and don't tune its numbers, so similar to section 3, but it needs to be in non-RF channel range. I would need to find some range for it, maybe 49-up? Or 17-32? (assuming I will never transmit more than 16 channels)

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.

mawzthefinn commented 1 year ago

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.

  1. 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.

  2. 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.

  3. 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)

azaz44 commented 1 year ago

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.

  1. 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.

  1. 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:

image

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 :)

  1. 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.

mawzthefinn commented 1 year ago

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.

azaz44 commented 1 year ago

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.

mawzthefinn commented 1 year ago

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)

azaz44 commented 1 year ago

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..

bsongis-frsky commented 1 year ago

This feature will be in the next nightlies!

mawzthefinn commented 1 year ago

@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.,

azaz44 commented 1 year ago

@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 👍

azaz44 commented 1 year ago

@bsongis-frsky Simulators are not there, will they come too?

RC-SOAR commented 1 year ago

Unfortunately I've not had a chance to install the nightly in order to check out the new feature - hopefully today or tomorrow.

fhpage commented 1 year ago

@bsongis-frsky Will there be new nightly for X10S?

loetefix commented 1 year ago

If we use a switch or a button to inc/dec a value , it inc / dec way too fast. Please make the Interval adjustable.

hrenz commented 1 year ago

what we need for this switch or Button inc, dec, with steps and repeating time autoset and autoreset Range with Clipping

mawzthefinn commented 1 year ago

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