2.1.7 Mixer delay bug (and a lot of head scratching)

[athertop]

I think I have identified a bug in OpenTx 2.1.7 on Taranis Plus.

I have the following mixes set up for Ch5 which controls my APM:Plane flight modes thus:

So there are two 3-pos switches controlling 5 different flight modes. With SG in the up position, SD is fully effective. Up and down delay is set to 0.3sec for each mix. This is the basis for the following example of the issue:

I change from SD (up) to SD (down) quickly, expecting (due to the 0.3s delay configured) that the output on Ch5 would go from -60 to +60 directly (without any effect from the switch centre position I am briefly passing through), but what I see on the channel output as the switch changes position is: -60 -40 +60, with the -40 only appearing very briefly, suggesting that SD(centre) is still being applied for a brief moment. This is enough for the flight controller software to see this as two separate flight mode changes. On further examination, this happens only on a downward switch movement of 2 places. It always switches to the middle position for a brief moment. The same happens using SG if I switch from SG(up) to SG(down) in one fast movement, it will always momentarily switch the output to that of the middle switch position before moving quickly on to the output from the switch down position. Moving the switch upwards, I do not see this issue (it switches channel value directly).
If I remove the 0.3sec delay on each mix, then I can switch SD quickly enough for this to not be an issue, but the delay seems to introduce this issue.

Any advice on achieving a direct switch of values would be really appreciated. Is this a bug or have I missed something silly?? This can be replicated in the Companion simulator by dragging SD from fully up to fully down (clicking between up and down does no replicate this issue).

(please feel free to quit reading at this point as the following is not important to the above issue):
I have also experimented using 5 Logical Switches based on the same switch position combinations and configured my CH5 mixes to use these 5 Logical switches (instead of the physical ones as above), but this seems to highlight a different issue (not a bug though this time).

I configured 5 logical switches L11 to L15 as follows:

(this mirrors the switch combinations in my original Ch5 mix above)

Then my 5 mixes for Ch5 as follows:

Screen Shot 2016-03-27 at 14.51.59.jpg (23.01 KiB) Viewed 5893 times

(as you can see there are no delays set in any of these mixes)

Again, I tested this with SG(up), such that the three positions of SD are fully effective. I then see the following issue:

Changing from SD(up) to SD(down), I see the output on Ch5 change from -60 to 0 then to +60. My issue here is that it changes briefly to zero (the time spent at zero seems to correspond with the length of the delay applied to the Logical switch. In fact, even switching just one position on that 3 pos switch does exactly the same.

What is happening logically here during the switch from SD(up) to SD(down) is that as soon as the switch moves away from SD(up), L11 changes from TRUE to FALSE, but L13 does not become TRUE yet for another 0.3 seconds, and therefore there is a null state during this time, so the output becomes zero for 0.3 seconds, then L13 becomes TRUE. This NULL state generates a channel value of zero (which equates to roughly 1500us PWM value, which corresponds with a flight mode, so once again the flight controller sees the switch change as two flight mode changes in quick succession. (Incidentally, I have this delay set intentionally to prevent intermediate switch position flight mode voices from being called out (as my flight mode voices are triggered by these switches also).

So what happens if I add a delay on the mixer configurations also - say, I add a 0.4s delay against up and down on each of those mixes (0.4s being longer than the 0.3s delay on the Logical switches). The results are even more bizarre. To further try and understand the logic behind the delays I changed the mixer delays to 3 seconds. The results - not exactly sure how to figure the logic behind what I see!
This is what happens:
Switching from SD(up) to SD(down) shows -60 0 40. I.e. causes a brief shift to the zero value during the switch
Switching from SD(down)to SD(up) shows 40 -60. I.e a clean switch (so no pause on a zero value during the switch)
Switching from SD(up) to SD(middle) shows 60 0 -20. I.e. causes a brief shift to the zero value during the switch
Switching from SD(middle) to SD(up) shows -20 -60. I.e a clean switch (so no pause on a zero value during the switch)
Switching from SD(middle) to SD(down) shows -20 40. I.e a clean switch (so no pause on a zero value during the switch)
Switching from SD(down) to SD(middle) shows 40 0 -20. I.e. causes a brief shift to the zero value during the switch

I am trying to see a pattern here to this strange behaviour but haven’t spotted it yet.

[Kilrah]

You should only ever have ONE line with a slow on a given channel, not more.

[athertop]

You should only ever have ONE line with a slow on a given channel, not more.

I am using 'delay up/dn', rather than 'slow'. Is this comment valid to the delay configuration also?

I have just tested putting the up/down delay to 0.3s on only the first mix line for Ch5 (as per my original screenshot in OP), and this causes even stranger behaviour. On changing from SD(up) to SD(down) I get the output going cleanly from -60 to +60 - perfect! But then on switching from SD(down) to SD(up) quickly, I see the output go +60 0 -60 (so it momentarily stops at zero which is very strange!)

If I instead apply delay up/dn of 0.3s to only the second mix line for Ch5, then I get my original observation (from my OP). So changing from AD(up) to SD(down), I see the output -60 +60 (perfect!), but if I then do SD(down) to SD(up), I see the middle position output momentarily being output, so I get +60 -40 -60

So even stranger behaviour with delay set just to one mix, and different outcome depending on which mix this is applied to for this channel.

[Kilrah]

Delay and slow work on a change of the source value, not on activation/deactivation of a line. If you set your source as the throttle stick and move it the dealy/slow will be applied to it.
You use them on source MAX, which never varies so in any case you're not going to get the behavior you expect.

[athertop]

Delay and slow work on a change of the source value, not on activation/deactivation of a line. If you set your source as the throttle stick and move it the dealy/slow will be applied to it.
You use them on source MAX, which never varies so in any case you're not going to get the behavior you expect.

Thanks for the insight Kilrah. Much appreciated. It makes me wonder though, if slow/delay is only based on the source, how the different delay configurations detailed in my last post, are having such an effect on the output; given that, and as you correctly state, I am using MAX values - obviously different max values in each line (as my weight is different in each), but it definitely has an effect. Wondering then that perhaps there is some hidden issue in the mixer code? I recall seeing an issue on github with mixer code, which you suggest that the mixer code may be refactored before long. If this is the case, would it be worth including a new option in the new code which allows an output delay to be applied? In other words, if some variables are changed forcing a channel mix to switch to a different output value (either based on changing inputs or even if a condition forces a different mix line to come into effect for that channel, which ultimately effects the output), then the delay will be applied from the point of first change, such that the output value will remain the same until the end of the delay where the new current output value will come into effect?

Just some thought!

Cheers, Paul

[MikeB]

I thought MAX is a special case and delay/slow do apply to the change of enabling/disabling a mix with MAX as source.

Mike.

[Kilrah]

Not at this point as far as I know.
The rule is basically not to switch a line with slow or delay on/off. Yes that would be part of a huge refactoring. Not easy at all given the various intertwined things (flight modes which have their own slows etc), even less when you have to make sure whatever is changed should not cause any change in any existing "properly configured" model.

In your case all these MAX lines should go in an Input, and in the mixer you just have 100% [input] and the delay.

[MikeB]

I just tested a mix line with MAX and slow in Companion 2.0.15, and the slow function DOES operate when the mix is enabled/disabled.
This is the way er9x worked (and still does) before openTx was forked from it.

Mike.

[Kilrah]

But now add a second line that also has a slow/delay and I believe you'll see jumps when the 2nd line starts using the last value of the previous one.

[MikeB]

You may see jumps, but the mix with MAX as source itself should behave as I described.
My understanding of the way MAX works (unless it has changed recently), is when the mix is enabled the mix outputs the weight, and when the mix is disabled, the mix outputs 0%, so then 'input' value does change (sort of), so delay and slow do operate.

Mike.

[athertop]

In your case all these MAX lines should go in an Input, and in the mixer you just have 100% [input] and the delay.

Kilrah, you are indeed a font of great knowledge! Thanks for this info. I just setup 5 Logical switches each using ANDs based on positions of my 2 switches SD and SG, each to represent a flight mode, and using special functions for each switch, assign different values to GV1, then I created an input called [i6]Test, with source of MAX and weight of GV1. Then in the mixer, used this [i6]test as the source for channel 5 (I.e. my flight mode channel). Then added the delay of 0.3s to ch5 and it works perfectly!

Update, Decided to use flight modes In OpenTX to set the GV1 value. Cuts down on special functions and keeps things tidy.

[Kilrah]

Works too.