Butterfly mixer: applicate new "input range" only in case no dedicated input curve choosen

[strgaltdel]

Yesterday we had an "intensive" discussion about the change of the butterfly "input behaviour" offered in 1.2.11 in engelmt forum. There were two groups ,one thinking "mostly right in case the 200% adoption is released" and the other "and now the butterfly is completely messed up" until one guy recognized why we had so extremely different views about the now released change.

The "input" is mapped from travel range -100%...+100% to a range from 0%..100%

• so far so good for users who won't ponder about finetuning butterfly mixer like an advanced user will do

BUT and this is a big "BUT":

In case an advanced user will use customed curves (or has updated ethos with configs using customized curves) the "old/existing" butterfly mixer is unusable even considering the 1.2.12 proposed "200% implementation" without defining new curves for all of his models.

This resulted in a hot debate

example:

here you can see the user can't use the "negative" part of his old curve

SIMPLE PROPOSAL TO ELIMININATE THE PROBLEM: (1) application of "input mapping" only if user didn't configure customized curves

.. so existing configs with curves wouldn't be compromized

MORE ADVANCED PROPOSAL

Based on the feedback of the group mentioned above Everybody was more or less wondering about the "kind of implementation/visualisation" of the new input changes.. We would have expected a mapping on "Y-axis", not on "X-axis" Now the user "sees" a curve pivoting at zero point without accessing the negative part of the x-axis That seemed disturbing for most of the user

In case the standard user doesnt't choose a dedicated curve, use a predefined (hardcoded) "butterfly curve" like this (10% deadband, range 0..100% on Y-axes) as standard, INSTEAD OF MAPPING THE RANGE/TRAVEL

example:

...or "map" the y-axis, not the x-axis.

so the user is not suprized about "visualisation"

In every case, please implement the 200% extension in next release

regards

[Tonio62]

Totally agree with you ! 1.2.10 works perfectly with butterfly on my Big Ceres... Now i had to change the curve and the processus is less natural to programming

[aalain8]

Hello, the butterfly mixer must have a ready mix for those who discover Ethos, the 1.2.11 does it and it's very good.

Unfortunately the 1.2.11 modifies the settings of existing gliders and does not simplify the settings for those, like me, who have several F5J gliders. I have to retouch all the curves and the graphic is disturbing me!!!

The pictures of "strgaltdel" show a more meaningful graph (for a butterfly) Moreover we see a dead band which is very important for the gliders.

If the 1.2.12 had an optional "dead band" box I could live with it.

[hrenz]

Butterfly with curve 0 to 100 or -100 to +100 the finished curve should be available as an option at startup but you should be able to overwrite it with your own curve at any time.

so that every user of Butterfly has his necessary freedom.

[jfint]

Honestly I'm still just hoping for a separate curve for elevator. That has been ignored and I have to run two mixes on everything as a result.

[RC-SOAR]

Just a couple of comments.

IMO integrating the input curve as a hidden component is causing more problems than it solves. One solution might be to provide it as a predefined regular curve, which users could modify themselves, for example to include some deadband.

I would suggest also a separate Always On 'Flap offset' mix, as with some Futaba radios. This is a simple way to deal with the offset neutral which results from the asymmetric up/down travel of the flaps.

I do this now as a free mix with a MAX or VAR input, and two outputs to the flaps. However including it as a named mix would encourage its use. The benefit: the output of the Butterfly mix could start from zero, and the flap travel would be adjusted simply by setting the weight. Another benefit: disabling the Butterfly mix would not affect the flap neutral.

So yes two mixes are needed. The main reason being that the flap offset must be Always On. Butterfly mixes and asymmetric flaps are complicated, maybe we just accept that.

[lthole]

I fully support RC-SOAR’s proposal: a) Instead of the hidden single-sided curve, provide a predefined regular curve which users can modify if desired. However I would include a deadband in the predefined curve. b) Add a ‘Flap Offset’ mix to the mixer library.

And also the already-requested increase of flaps Weight to 200%.

And finally allow a compensation curve to be added for non-linear Elevator compensation.

[Eagleowl1]

I also support RC-SOAR and lthole three proposals.

Most of us are not only flying models with flaps acting only downwards. (typically Butterfly) but also AIL=>FLAPS and CAMBER on the same model.

Regarding WEIGHTS: it would be so convenient to have the ability to adjust up and down deflections separetly for every channels involded in evey "wing" mixers, rather than globally as proposed today. (or at least adding a differential option in CAMBER same as found in AIL->FLAPS. (e.g. typical CAMBER setup : 2% up and 15% down).

Off course ETHOS offers go around solutions, but imo aiming to be a high performance "easy to use" OS, ergonomy is a priority. Imo again, today is not anymore about feasibility, it is about how easy you can achieve it. Being quite new to Frsky (ETHOS only) I am really impressed by the high standard of the OS ecosystem as delivered today. (Sorry for the digression)

[bsongis]

Andreas from Engel sent me a document about a Butterfly proposal, following the discussion on a group.

I have to say a couple of things:

1) We will keep stacked mixes: => they give more freedom to the pilot, in Ethos we like to speak of Mix functions (Ailerons / Flaps / Butterfly / etc.)

2) We won't add the offset INSIDE the mix configuration, at least not the way it's described in the document: => it the pilot wants to mix on the same surface functions like Ailerons + Flaps + Butterfly, which one would keep the offset? and now what will happen if he removes this function with the offset included? the offset must be ALWAYS ON and in my opinion it should be set before the other functions

3) We don't like too much the "hidden" things. Instead we do like the approach of "Embedded curve" (predefined) as described by lthole earlier, as it seems perfectly compatible with Ethos philosophy, and it allows to use another "External curve"

4) The curve for Elevator compensation - as required above by jfint - seems indeed mandatory, it will be prioritized as so

5) The "Flap Offset" Mix should be added, to avoid the use of a Free Mix, it will be very very simple, without Slow Up / Slow down / Offset / Curve, just one Weight per output. Weight can be configured by a Pot / Slider, and it will be possible to use a GVar there (when the implementation of GVars will be finished)

[RC-SOAR]

Thank you, Bertrand. Could you just clarify point 3 please - the hidden curve will be moved to the regular input curve, and it will be editable? I think and hope that is the case. The rest of the points are clear and I think will make a good solution.

[bsongis]

Yes of course this curve will be editable, I just mean that it will be part of the mix, and not visible in the Model / Curves. It also means that when you delete the butterfly, you will delete the curve in the same time.

[Eagleowl1]

Since there is a lot of discussion about the Butterfly setting here are 2 screens copies of my 6M Arcus (4 Ail + 4 Flaps)

It might be interesting to see how competition coped with this challenge (around 18 years ago T14MZ) Purpose of this post is purely informative as I am personally fully satisfied with ETHOS and confident with the improvements to come.

Please note:

• Offset in BUTTERFLY is added to the one set in FLAP SETTING (if set to 0 in Butterfly, Flap offset remains effective)
• A separate differential is available in BUTTERFLY (some people mentionned this wish)

in case of interest I have more screen shots available

[hrenz]

the hardcoded curve in the butterfly mixer means that it can no longer be used universally. This hardcoded curve should be visible as a normal preset curve, so that you can edit it at any time. Then the butterfly mixer would be universally usable again.

Please change like this

Thanks

[bsongis]

@Eagleowl1

1) About the offset. It is effective when the Butterfly is OFF? It's exactly what I don't like, as stated above. The Offset Mix is a better approach in my opinion.

2) Differential in Butterfly. What will it do? Isn't a curve a perfect solution for this?

@hrenz

It seems you haven't read my post correctly

[RC-SOAR]

Yes, separate offset mix is the way to go.

Regarding aileron diff, a common requirement on high performance sailplanes is to reduce diff automatically, as butterfly is deployed - the purpose is to improve roll response as the ailerons rise. However this behaviour can be implemented through the existing mechanisms (in the Ailerons mix, set the Diff value to a source instead of constant value).

[Eagleowl1]

@Eagleowl1

1. About the offset. It is effective when the Butterfly is OFF? It's exactly what I don't like, as stated above. The Offset Mix is a better approach in my opinion.
2. Differential in Butterfly. What will it do? Isn't a curve a perfect solution for this?

Fully agree with you Offset must stay active all the time. On pic 2: offset label is misleading as it defines the point where the source becomes effective. In this case 15% below throtle max. (redundant with the source curve which can be defined with "Butterfly AFR"

pic 2 bottom: Differential in butterfly allows to modify (mostly reduce or reverse defined differential) for better aileron efficiency during landing.

My post Jul 2nd Agree with you: curves are the right aproach. Sometimes I am still a bit "hooked" to my habits with other system approach.

I am happy with the current implementation of Butterfly and Offset. The only thing I do not understand is the reason for having Butterfly active only on 50% of the X axis?

[Eagleowl1]

Yes, separate offset mix is the way to go.

Regarding aileron diff, a common requirement on high performance sailplanes is to reduce diff automatically, as butterfly is deployed - the purpose is to improve roll response as the ailerons rise. However this behaviour can be implemented through the existing mechanisms (in the Ailerons mix, set the Diff value to a source instead of constant value).

Agree with your point: however "additional weight" for differential would be required. e.g. Throttle source used for Motor and also for Butterfly in another flight mode

Or did I miss something?

[strgaltdel]

https://user-images.githubusercontent.com/20392683/187639984-fac4f2e9-057a-480c-9186-74743cd027f8.mp4

"Whats is it about Diff in Butterfly?"

maybe a video tells more than 1000 words in this video you can see a standard config in the first 14 seconds 4 flaps, diff set to app. 50%

until BF is half deployed you get aileron deflection which should be fullfill most demands , but in full Butterfly you will get nearly zero roll rate, only yaw because ailerons are more braking (yaw) then pushing a wing down / pulling up (roll)

At sec14 i do activate a "progressive anti diff" component. (zero component in BF closed, half at half butterfly, full "anti-diff" at bf full deployed) This mixer adds ail deflection downwards beyond the neutral point.

Would like to see this functionality within BF Mixer

[RC-SOAR]

Regarding aileron diff, a common requirement on high performance sailplanes is to reduce diff automatically, as butterfly is deployed - the purpose is to improve roll response as the ailerons rise. However this behaviour can be implemented through the existing mechanisms (in the Ailerons mix, set the Diff value to a source instead of constant value).

Agree with your point: however "additional weight" for differential would be required. e.g. Throttle source used for Motor and also for Butterfly in another flight mode

Or did I miss something?

Yes, the diff calculation may be quite complex, requiring an intermediate channel. But it is possible.

(In my sailplane templates, there are separate free mixes for up/down aileron travel. The down-travel calculation is also done using free mixers, taking into account the effective butterfly value.)

[strgaltdel]

Yes, the diff calculation may be quite complex, requiring an intermediate channel. But it is possible.

totally agree and would say "you nailed it".

Basically we are not discussing any points/problems that can not already be implemented by now, (I would say the additional implementation of "antiDiff" is even more elegant than in oTx) we are discussing the "usability" of implementations for the average user, who might have switched from other brands that (sometimes) offer more features in a canned mixer, and who doesn't want to think about complex mixer solutions to achieve his goal.

If someone has switched from otx and felt comfortable there, ethos should not be a hurdle to meet all their needs by stacking mixers.

[RC-SOAR]

we are discussing the "usability" of implementations for the average user, who might have switched from other brands that (sometimes) offer more features in a canned mixer, and who doesn't want to think about complex mixer solutions to achieve his goal.

I don't disagree. The ideal would be an option in the Butterfly mix, to suppress diff in the Ailerons mix. But how would this work? It would involve an interaction between two mixers - but In Ethos, mixers are stacked and must be independent.

Another 'solution' might be a mix with two inputs: (a) aileron stick and (b) throttle stick. Then you could control all the internal dependencies including diff, and add lots of other options as well. But it would break another convention of Ethos, which is just one input for each mix.

If the devs were prepare to break the existing Ethos model of (a) mixer independence, and (b) one input per mix, then perhaps the 'ideal' solution would be possible, with very complex mixing screens, like on some other radios. But that would completely change the character of Ethos. Although there are inevitable compromises - like here - on balance I'm happy with the current approach.

[bsongis-frsky]

Perhaps an option in the Mix to disable the differential in some condition would help? It could be a Logic Switch named "Butterfly", it would be even easier to read

[Eagleowl1]

Basically we are not discussing any points/problems that can not already be implemented by now, (I would say the additional implementation of "antiDiff" is even more elegant than in oTx) we are discussing the "usability" of implementations for the average user, who might have switched from other brands that (sometimes) offer more features in a canned mixer, and who doesn't want to think about complex mixer solutions to achieve his goal.

This reflects my view too. Usability is a key element in aquiring new "average(?)" users. So much is already implented in Ethos in this regard!

Perhaps an option in the Mix to disable the differential in some condition would help? It could be a Logic Switch named "Butterfly", it would be even easier to read

Yes sounds very good. I have no idea about the intangible Ethos rules and programing complexity, but I think about the ability to allow Analog source to switch Flight modes or Logic switch (see my proposal about this sent today) #1895

[strgaltdel]

I guess it was my old "80ies MPX3030 master edition" which worked this way.

You could enter a "threshold" value in the Butterfly mixer. In case the input exceeded this threshold value Diff was disabled.

[hrenz]

Sorry Bertrand but we are talking past each other Throttle stick has 2 Funtions: Motor with the throttle stick from middle updwards 0% to +100% Butterfly with the throttle stick from the middle backwards 0% to -100% to extend the butterfly linear is no longer possible.

because the hidden curves only allows 0% to +100%. with the throttel stick and its also not editable.

It works like openTX, Input, with Weight 50%, Offset 5%

[jfint]

@bsongis This was closed but the elevator seperate curve was not implemented? This should be reopened, or a seperate issue tracked.

[bsongis-frsky]

I think I pressed the wrong button and closed the issue by mistake when writing the last proposal!