Feature Request: Re-label Mode function

More
26 Jan 2014 13:09 - 26 Jan 2014 13:14 #19144 by VTdev
If the "Mode" function in the user interface were instead called "Channel Order" (or similar) and the choices re-labeled from "Mode 1" Mode 2, etc. to EATR, TAER, it would hold true for all protocols. No code changes would be required except a UI name change and a manual explanation change.

And in fact this is what the control truly does. It sets a default global (Tx)channel order. THAT doesn't change with protocol changes. It's always true.

The confusion comes when trying to use the word "Mode". Mode to 99% of users refers to which stick the throttle is on, but Mode in a devolution modified DEVO transmitter no longer is an accurate name in all the available protocols. (I suppose you could make it true by a lot of extra programming to sense protocol -- but why not just change the name to avoid all that?)

Any function that users set should hold true across protocols and make sense logically to avoid errors in setup.

I think the "Mode" designation, nowadays is, well, outmoded.....
Last edit: 26 Jan 2014 13:14 by VTdev.
The topic has been locked.
  • rbe2012
  • rbe2012's Avatar
  • Offline
  • So much to do, so little time...
More
26 Jan 2014 14:10 #19150 by rbe2012
Replied by rbe2012 on topic Feature Request: Re-label Mode function
For me the "mode" is still one of the fundamental characteristic of a rc transmitter. It's not only a question of which stick controls which channels. It is also a mechanical difference which stick is centered (with springs) and which is not.
So I still think that "mode" is a criteria which is well-known (you have to mention it for nearly every RTF order).

It will be much better to make a new try to reorder the channels correctly.
The topic has been locked.
More
26 Jan 2014 14:16 - 26 Jan 2014 14:17 #19151 by HappyHarry
Replied by HappyHarry on topic Feature Request: Re-label Mode function
is it not simply a case of mirroring what the standard gui does? as that changes channel output order per protocol iirc?
Last edit: 26 Jan 2014 14:17 by HappyHarry.
The topic has been locked.
More
26 Jan 2014 14:30 - 26 Jan 2014 14:32 #19152 by WheresWaldo
Replied by WheresWaldo on topic Feature Request: Re-label Mode function
I agree with rbe2012 on this one, Mode is a physical layout and must follow accepted industry standards, Protocols have specific channel layouts and the Advanced mixer should respect those.

the Devo / DSM switch could possibly cause an injury if you always expect the throttle to be on the spring loaded stick and suddenly find it at 0 instead of -100 when you switch protocols.
Last edit: 26 Jan 2014 14:32 by WheresWaldo.
The topic has been locked.
More
26 Jan 2014 15:19 - 26 Jan 2014 15:24 #19157 by VTdev
Replied by VTdev on topic Feature Request: Re-label Mode function
If it's possible to make mode consistent via programming then, that would be great. I thought that practical concerns meant that it wasn't going to be changed, and so, as an alternative I proposed at least changing the naming scheme to reflect what actually happens when you select a mode presently -- that is a channel reassignment that does not necessarily correlate to a particular real world "Mode".

I agree, that the more complicated solution is better.
Last edit: 26 Jan 2014 15:24 by VTdev.
The topic has been locked.
More
26 Jan 2014 15:57 #19160 by VTdev
Replied by VTdev on topic Feature Request: Re-label Mode function
Until someone comes up with a solution, it might be wise to include a warning message at the head of the instruction manual -- something like this:

Warning: when changing protocols from DEVO to DSM2 [and any other applicble protocols -etc.] MODE numbers are no longer representative, unless you also mix throttle to channel 1 and elevator to channel 3 in the Mixer BEFORE BINDING A RECEIVER.

Otherwise the receiver may bind to a centered stick, and may run the motor when it loses a signal. This can happen when shutting the TX off before the receiver.
The topic has been locked.
More
26 Jan 2014 16:37 #19165 by FDR
Replied by FDR on topic Feature Request: Re-label Mode function
Please do understand, that the mode has nothing to do with the channel order of different protocols.
We can discuss anything only after that...
The topic has been locked.
More
26 Jan 2014 16:41 #19168 by PhracturedBlue
Replied by PhracturedBlue on topic Feature Request: Re-label Mode function
This discussion is not going anywhere. I understand VTdev's position that he can achieve his goals by misusing a Deviation capability, but I'm not going to change the documentation to encourage that behavior.

The right message would be something along the lines of:
Whenever changing the protocol, you must ensure that the channel assignments are correct

But by the time the next release is out, I expect the underlying issue is likely to be dealt with.
The topic has been locked.
More
26 Jan 2014 16:59 #19170 by PhracturedBlue
Replied by PhracturedBlue on topic Feature Request: Re-label Mode function
Actually...I just checked in code that should behave in the expected way. It definitely needs testing to make sure it works in all situations though. The channels will be reordered automatically when changing protocols now.
The topic has been locked.
More
26 Jan 2014 17:05 #19172 by WheresWaldo
Replied by WheresWaldo on topic Feature Request: Re-label Mode function

FDR wrote: Please do understand, that the mode has nothing to do with the channel order of different protocols.
We can discuss anything only after that...


FDR, this discussion is / was spread out between too many threads, could we either consolidate or close the other threads, it seems PB has already addressed this with a code change, I will be able to test this tomorrow as I am at work today.
The topic has been locked.
More
26 Jan 2014 17:12 #19178 by PhracturedBlue
Replied by PhracturedBlue on topic Feature Request: Re-label Mode function
As was said elsewhere, this was tried before. We'll need a lot of testing on this to find where it breaks and what needs to be fixed.

I will start a new thread without the baggage. this one is done.
The topic has been locked.
Time to create page: 0.053 seconds
Powered by Kunena Forum