Full throttle when 7e Tx turned off

Devo 7e,
fresh install of 7e-v4.0.1
Model type: Aircraft
DSM2
Mode 1 set (also a bug -- this is a mode 2 Tx, but I had to set mode 1 to get the throttle on the left stick. Otherwise it was on the right stick.

Receiver: Orange receiver -- formerly working correctly in model with Spektrum Dx6i.

The transmitter was inadvertently switched off before the receiver, with throttle off. and the model instantly went to full throttle.

Testing this, it is repeatable.

I do not know if this is related to the mode 2 -- mode 1 problem.

Did you make any changes in the mixer section? With dsm/dsmx you have to reset the source because the channel order is different.

When binding to the 7E did set up the failsafe on the rx correctly ...

Make sure that your channel mapping is correct. The easiest way:
- load an unused model config (a model where the name is "None")
- switch protocol to dsm2
- load template for plane (simple 4 channel or airplane 6 channel)
Now your channel mapping should be THR - AIL - ELE - RUD (- HOLD - CH6).
This way you don't have to change the mode of the tx (set it back to mode2!) since the remapping due to the order the protocol needs is already done.
Now you should bind (maybe bind plug necessary, I actually don't remember if the safety values are saved when binding with plug or with every binding) and the values from the tx at this moment (thr=min, rest=0) should be taken as safety values.
Make sure to take some care when testing.

rbe2012 wrote: I actually don't remember if the safety values are saved when binding with plug or with every binding) and the values from the tx at this moment (thr=min, rest=0) should be taken as safety values.

Only while binding with plug but two different ways might be available depending on the type of the Rx (e.g. see R710 manual).

VTdev: You bound the model with half trottle. This is not a mode 1 or 2 issue. DSM Rx do have a different channel order for ELE and THR.

Thank you all for responding. I've had a fair amount of discussion on this today.

It is a mode problem in the sense that Mode 2 selection under DSM2 protocol by default does not yield expected results. It maps Channel 1 to the right stick, when it should map Channel 1 to the left stick.

Mode 1 does map Channel 1 to the left stick.

At present the choice of "MODE" is purposeless -- Selecting Mode 2 will not necessarily yield Mode 2, depending on other circumstances. Better to label the modes A,B,C,D, or eliminate them, rather than have them work under some protocols and not others.

Mode 2 means mode 2 -- throttle on left. The problem with using a well understood label for something, and and having an unexpected and opposite result can be severe.

It can be seen also as a software bug.

Here are the steps to reproduce:

Step 1
Load default model in default system.
Step 2.
Select DSM2 for model, Mode 2 for TX
Step 3.
Turn off Tx
Step 4
Turn on Tx

Warning message:
"CH1 is 0%
safe value = -100%"

With regard to the throttle running on shut-down, yes this was a result of binding under the mistaken impression that Mode 2 worked as expected.

When I re-set the Tx to Mode 1 and re-bound. Everything worked as expected.

However Choosing Mode 1 is a non-intuitive choice, when you want Mode 2.

I can confirm that what VTDev is describing is correct. It appears that the mode selection does nothing after the initial setting.

In Mode 1 switching a model from DEVO to DSM should change the right stick up/down from channel 3 EATR (Devo throttle) to Channel 1 TAER (DSM throttle), but it doesn't. Similarly Mode 2 left stick up/down should do the same on protocol change.

This is for the advanced mixer, the standard mixer works as expected switching channels based on protocols, Mode works as expected.

From my cursory investigation this is not a Mode issue it is a channel mapping / protocol issue.

WheresWaldo wrote: From my cursory investigation this is not a Mode issue it is a channel mapping issue.

Correct, sorry if I mis-stated.

Did you file a ticket on PB's bitbucket repository, it is a show stopping bug.

I did, unfortunately anonymously -- didn't realize username from here didn't apply. So haven't been able to edit original report.

PB has answered and asked for the ini. Please look at the issue from time to time because when you open in anonymously, you can't receive status updates.

The problem itself is well known. A while ago I made an approach to change all the elements which belong to a specific channel when the channel is remapped due to protocol change. But we had some strange side effects so we decided to walk back.

Thanks rbe I've checked and responded to the issue on bitbucket, and also included the model.ini here on the forum.

I'm interested in what those strange side effects were.

The normal advice, at present, to users is: when selecting protocol DSM2, to also change the channel assignments in the mixer to THR-->CH1 and ELE-->CH3.

The user can alternatively be seen as part of a "system" such that:

If DSM2 = true, then THR-->CH1 and ELE-->CH3.

If you simply program that into the firmware as an automatic response, the effects of that should be exactly the same as if a person made that election.

So why would there be any strange effects?

Or conversely, why wouldn't strange effects also occur if a person did that?

Drop the sarcasm, I'm trying to help. I'm asking a legitimate question, if you don't want to answer it, fine.

jfyi pb has just pushed the commit that changes the channel ordering per protocol >> deviationtx.com/forum/7-development/2684...-mode-function#19170

VTdev wrote: Drop the sarcasm, I'm trying to help. I'm asking a legitimate question, if you don't want to answer it, fine.

VTdev, don't take it as sarcasm, it is just a difference between US and Euro. Is it possible for you to close this thread as you are the author of it and there is new code that needs checking to test, if not the FDR will need to close it.

I ask because this issue appears to be in multiple threads and goes no where if it is not consolidated.

Sure, I will close the thread.