Differential not applied the same way in Inputs and Mixers

[pindeslandes]

Taranis. Since OpenTx 2.0, the offset in a mixer line is applied after weight and curve instead of being the first operation. And so it is for inputs. Example with differential and offset on an input:

Easy to see that the offset is applied after the differential: all is right, so far.

Now if you do exactly the same in a mixer (-50 offset and 100 differential in that case), you will see that y stays to 0 when x < 50, meaning offset is applied BEFORE differential. It seems that differential is the only exception: no such issue with other curves.

[hrenz]

Hy pindeslandes, know problem, there are two errors at Differential-Function look at #1807 with a curve it works, with Diff-Function not allways (depending of value of offset) Helle

[pindeslandes]

Yes indeed, hrenz, the first error you are referring to is the same as the one I issued right above (sorry, I missed it). But the second one is not an error, I believe. It seems to work the way it should because in many cases, you actually need to reduce the positive side. Anyway, it’s strange no developer has reacted to your first issue yet because it’s a true and serious one, in my opinion. Maybe they missed it as I did :-)

[hrenz]

Hy, the differential funktion is a funktion to decrease or increase a (Ail) ruder at the lower side only pos diff reduces the (Ail) ruder lower side, this is the normal diff-funktion neg diff increases the (Ail) ruder at lower side, its a so called negativ diff-funktion Implemented is a decrese at the upper side, but this ist not a real negativ diff-funktion

Especially for gliders you need often a negativ Diff Funktion selection by a switch with no change at the uper side

I know we can solve this with two or three curves, but then I don't need a diff-funktion

Helle

[pindeslandes]

Yes, I know, my Futaba does as you say. My point was: being different doesn’t necessary mean being wrong. OpenTx has a different logic but it isn’t illogical. But I should let the developers answer here! IMO, the most important issue is that differential doesn’t work the same way in Inputs and Mixers.

[RC-SOAR]

Well I'm not a dev but have grappled and worked around this issue for my F3F setup.

A couple of points... first, to implement aileron diff, you need to specify diff for each ail servo at the mixer level (not input level). Second, if you do it the obvious way using just a single mixer line per servo, the crossover for diff shifts away from stick centre as trim is applied. Agreed, this is not desirable behaviour (though it's the same on my Multiplex 4000).

At least with OpenTx the solution is simple: split the aileron mix into two lines: in the aileron mix, set trim=no. Then add the trim back as a separate line. That way diff crossover stays at stick centre.

Channel for aileron servo:

src=Ail, diff = [put your diff here], trim=no
src=TrmA, wt=25%

I've not considered the case where a non-zero offset parameter is specified in the aileron mix, since this should never be necessary if the servos are correctly calibrated.

[pindeslandes]

Sure you can always find some workaround to almost any situation with OpenTx. That’s not the problem. The problem is that behaviour inconsistency.

Maybe another problem is that only users seem to be interested in that issue as no collaborator or developer as reacted for now!

[RC-SOAR]

OK just done some quick tests with mixers to see if I could understand the issue, using different

• curves (curve, diff, expo, func)
• offsets
• trim values

Results: Applying trim: consistent, trim is applied before curve in all cases. Applying mixer offset: not consistent offset is applied after curve in all cases except diff where offset is applied before.

Agree the second case looks like a bug because of the inconsistency. (Personally I cannot see the need for a non-zero offset in an aileron mix, so have never noticed it.)

As for the diff parameter in Inputs (as opposed to Mixers), if there is a problem, it's the confusing naming. Having 'diff' in Inputs suggests it might be used a high-level aileron diff function which it can't. Something like 'one-side rate' would be better IMO (though how that could be condensed is another issue).

[bsongis]

@RC-SOAR should it be changed? I mean diff always applied in the same place than curve? If yes I will change in 2.1

[bsongis]

It was done intentionnally and it complexifies a bit the mixer code, I will be glad to simplify it (diff applied in the same place than curve, before offset)

[RC-SOAR]

Thanks, just to clarify my understanding, there are two behaviour cases where the following are combined in a single mixer line (1) Diff & mixer offset, and (2) Diff & trim

1 - Diff + mixer offset: Diff appears to be the only curve-type to be applied after offset as the o/p found. IMO there is a good case to change order of processing, for consistency with other curve-types.

2 - Diff + trim: currently Diff is applied after Trim. IMO best not to change anything here. Where this behaviour is undesirable, the workaround is simple (add the trim in a separate mixer line). Also, diff is consistent with the other curve-types and other radios like the MPX 4000 work like this.

[davxlw]

Hi, I've just tested this mod and Diff before offset is better, but I would prefer it to be applied after weight, because when using a GV to set the diff, I now have to use -GV on one of the ailerons... Not a big deal...

[bsongis]

Are you saying that curves should be applied before weight while diff should be applied after? (both before offset)

[davxlw]

No, I didn't yet tried the curves, and now that I have, there isn't any difference for the curves to be before or after weight. Only diff is affected.

[bsongis]

I don't agree, if weight is negative there should be a difference!

[davxlw]

Yes, I've talked too quickly... After reflexion, as diff is also a curve, it must be applied like others, as it is now. So, sorry for the inconvenience :blush: , you can close it again...

[bsongis]

Excellent, thanks!

[bsongis]

We did something wrong here. The differential will be reworked in release 2.2.0 I revert this commit

[bsongis]

Part of the mixer rework done by @JivaroFAD