Spurious "intermediate" mode changes with Taranis X9D+ despite delay

I have the Taranis X9D+2019 set up with logical switches in order to obtain 6 mode possibilities with two three-position switches, as per the recommended setup in the general arducopter documentation here:
which is to say, 6 different pwm values on Channel 5.

The mode switching works successfully. However, during the act of switching the receiver to the desired mode, the receiver briefly sends out a pwm value of 2012 before settling on the new, proper value. For example, I have Loiter Mode at 988 and Auto Mode at 1306. When moving the switch between the two, however, I get a brief moment of 2012 and the AP thinks I want to go into Throw mode. Now, switching to Throw mode naturally fails because the appropriate conditions aren’t met, but it’s still not ideal because I get mavlink error messages, error messages in my log, etc.

I have tried two different methods for implementing the mode-switching within the Taranis.
Method 1) using six different logical switches, and on the mixer page including those logical switches with different offsets and weights
Method 2) using six different logical switches, leaving the mixer for ch5 empty, and adding 6 special functions that override channel five based on which logical switch is activated.

On method 1, I get a spurious signal that is 100% output to Ch5; for method 2, I get a spurious signal that is 0% output (middle) to Ch5.

For both methods, I have tried inserting delays into the Taranis, without success. I have tried placing delays on Ch5 in the mixer page for method 1. I have tried placing delays in the logical switches for method 1. I have tried placing delays in the logical switches for method 2. When I place a “delay up” on each of the entries in the mixer screen, it makes the situation worse–it immediately goes to the spurious value (either HIGH or MIDDLE) and then delays at that spurious value for the defined time before going to the appropriate value.

So, two courses of questions:
a) Is there a parameter in AP that permits a defined delay before accepting the new mode pwm value, to implement a time filter on switch changes?
b) if not, how do I get my Taranis to cooperate?

I solved my own problem, sort of. The Taranis has many different ways of accomplishing nearly the same thing. I changed around my whole paradigm and it seems to work. This is what I did:

  1. set up six entries on the Logical Switches page, using the “and” function, and entering the 6 permutations for the two three-position switches. Put a 0.5 second delay on all of them.
  2. on the Flight Modes page, set up six flight modes (starting with FM1, leave FM0 alone) with the right names, let the switch for each be the logical switch that corresponds to that mode
  3. on the Global Variables page, assign to GV1 the values -90, -40, -20, 10, 40, 80 to FM1 through FM6, respectively (long hold to change the number)
  4. on the Inputs page, set up one input with the name “Mode”, the Source “MAX,” and the Weight “GV1”
  5. on the Mixes page, set up Ch5 with Source to be whatever you just named your input (“Mode” in my example), and put a delay up and delay dn of 1.0 s
  6. on the Special Functions page, set up six special functions, with source FM1 to FM6, every one set to “Play Track”, and then choose the appropriate sound file for the flight mode

Now when I switch modes my values jump between the modes properly, with no intermediate values, and I get only one audible announcement for the new mode. As an added bonus, the mode name appears on the front screen as well (flight modes must show up there).

If anyone had improvements or if I’ve messed something up let me know.


It’s true I’ve replaced a pair of my Taranis swithes, SB and SD with 2-pos ones, but if you ignore the middle position from the 2nd switch in a 2-switch mix, the 6-pos Arducopter flight modes mix is as simple as this :

Or as simple as several other ways to configure flight modes with OpenTx. Is there really anything to see here?

The alternatives are 6 position switches in one form or another:

We have a couple of these and they work well, but are very small:

It’s easy to print a new label and stick on too. Inside the X9D there’s an unused pot input that you can connect this too, so you don’t even lose the two original pots.

It’s also worth the effort to set up Yaapu telemetry if possible. That way the telemetry calls out the flight mode change and you know that FC actually accepted it, or rejected it, instead of the transmitter calling out that it sent the flight mode change (but then what??)

I have the 6-pos knob on S2 on my upgraded Taranis, and I experienced the 6-button approach on a Radiomaster R/C. For not looking down at the remote in an emergency, the two-switch mix is faster and more precise and easy to handle.

True - that little six-button flight mode switcher is hard to find the correct switch in a hurry or without looking. A six position switch/knob would be better where can just turn it fully in one direction and know you’re going to hit Stabilize mode or whatever you’ve got set as your go-to mode.

yes, but I wasn’t having trouble with the basic mode-switching; I was having trouble with not “visiting” a random mode (or PWM value) in-between the switch changes. I don’t think that problem would be remedied with a six-position switch, because in-between rotations of the switch there is still a no-contact position where the value could go to an undesired value.

that’s a good point about the telemetry calling out the flight mode–how do I set that up? I have the Yaapu telemetry fully up and running, but it doesn’t call out a mode for me. What extra configuration do I have to do to get the Yaapu announcing flight modes instead of my special functions? thanks

I think just disable the flight mode sounds you set up in the radio. If you installed all the Yaapu files including the sounds, it should just work.
You’ll even get announcements like “Flight mode change failed”

If you have Yaapu telemetry script, let it handle itself. It’ll announce mode changes and fails, as well.
The radio handles the transitioning period between switch positions OK. It will hold the “last known” before the new position input kicks in. Just forget about logical switches and stuff. A simple mix will do.

The only use for logical switches I’ve encountered so far is simultaneous triggering of REC in two different logic cameras. One was recording while the PWM value was high, the second was toggling recording on and off after 100ms of high PWM value. Synching them took logical switching.

My AP definitely “hears” the intermediate mode switch and will switch to that in-between mode briefly (if it’s a valid mode to go to–if it’s not, it announces a mavlink error). It’s not just on the radio–it makes it to the FC. I’m skeptical that I should just be ignoring that. Besides, how do you switch modes from the radio without logical switches? (assuming you haven’t installed a custom 6-position switch that is, and you’re trying to use two switches in conjunction)

Sounds triggered only from switch activation are not that useful. Well, they were when that was the only option. They indicate you have flipped a switch. Sounds produced from actual functions being activated on the Flight controller are what you want. The Yaapu scripts give you that.

No luck with flight modes announced from Yaapu script after I disabled my special functions. I installed all the yaapu files including sounds, and it’s not working “out of the box”. Any suggestions for enabling that feature? I should add that I am using crossfire and the new csrf telemetry feature. I am successfully receiving telemetry to the yaapu script on the taranis, and it shows me the active flight mode, it just doesn’t speak it for me.

Maybe check the installation again, and that the sound files are actually there:

  • /SOUNDS/yaapu0/en
  • /SOUNDS/yaapu0/it
  • /SOUNDS/yaapu0/fr
  • /SOUNDS/yaapu0/de

I had the exact same trouble with my X9D+2019 radio.
I was implementing a delay in the MIXING page of .5 seconds to account for the time
between switching states . While everything functioned fine It was annoying getting the audio messages of all the flight modes in between as well as the final destination flight mode .
I fixed the problem by getting rid of the delays in the MIXING page .
Instead I implemented a .2 second delay in the LOGICAL SWITCH menu . I put a .2 second delay for all 6 logical switches ( Im using SE and SF switch for 6 modes )
So basically I’m getting a slight delay before the logical switch is implemented , so all
the logical switch states in between are never even arrived at .
No more multiple audio messages of in between flight modes

Yes, that was it. I had copied the sounds from inside the /SOUNDS/yaapu0/en directory into the /SOUNDS/en directory structure on my Taranis SD, rather than copying the /SOUNDS/yaapu0 directory in its entirety into the /SOUNDS directory on the card. I copied from one level too deep in the file structure… It works now, thank you for the suggestion.