Channel order and fail safes

[GoogleCodeExporter]

Channel order needs to be on a per model basis. It kind of is already but not 
visible or editable.

What steps will reproduce the problem?
1. Drop a hacked DX5 Spektrum module in
2. Set the Tx's channel order (TAER, correct for Spektrum)
3. Create a model
4. Bind and set failsafe
5. Drop a Futaba 2.4Ghz module in
6. Create another model
7. Bind and set failsafe

What is the expected output? 
Throttle channel on the Futaba receiver remembers the throttle stick position 
as failsafe.

What do you see instead?
It remembers the Elevator position. As Futaba channel order is AETR

I can get around this by doing this instead:

1. Drop a Spektrum module in
2. Set the Tx's channel order (TAER, correct for Spektrum)
3. Create a model
4. Bind and set failsafe
4a. Set the Tx's channel order (AETR, correct for Futaba)
5. Create a model
6. Drop a Futaba 2.4Ghz module in
7. Bind and set failsafe

Each model remembers the Rx channel order that was set at the time of creation, 
but there is no way to edit it or view it. 

I'm guessing EEGeneral.templateSetup is used to populate the MixData struct as 
the model is created and it is this that locks the channel order in place, guys 
??

Original issue reported on code.google.com by th9...@gmail.com on 9 Jan 2012 at 8:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

OK, you can view and edit the Rx channel order using the "MIXER" menu. Although 
re-ordering it isn't a very easy job. 

But I still think it a little confusing to have a Global setting that isn't 
really global. You follow ?

Maybe it should be a popup as you create a new model ? With the Global setting 
treated as the default. 

Anyone agree or is it just me ?

Original comment by th9...@gmail.com on 9 Jan 2012 at 8:28

[GoogleCodeExporter]

"I'm guessing EEGeneral.templateSetup is used to populate the MixData struct"
=> Right!

Perhaps if the protocol is DSM2, we just don't follow this EEGeneral parameter, 
but we always use TAER?

Original comment by bson...@gmail.com on 9 Jan 2012 at 10:06

[GoogleCodeExporter]

Yes, that's fine with me. This can be done if a model is already created with a 
different channel order ? What if lots of mixers exist and the user changes the 
modulation type, still ok ?

Original comment by th9...@gmail.com on 9 Jan 2012 at 11:11

[GoogleCodeExporter]

(I'm at 3 hours and 22 minutes for today's email processing, just got to here. 
:-/)

History: Originally, the only reason an RX channel order exists at all was for 
the templates system. Later, we made the TRAINER screen use the same setting. 
In that sense, it remains a global setting -- because the TRAINER menu is in 
the global settings. (I think the same is true now for the Expos screen as 
well?)

For the problem at hand -- in the longer term at least -- I would suggest that 
the Rx channel order ADDITIONALLY (see below re default) become a per-model 
setting. The channel order selection field should be read-only if DSM2 protocol 
is selected -- perhaps with an asterix (*) next to it.

The existing global rx channel order should still remain and be changed to 
read, "Default rx.ch.ord."

- - -

In the short term, we should probably opt for forced, auto-translation to TAER 
output order for DSM2 mode and change the name of DSM2 protocol to DSM2-TAER, 
as a reminder. (??)

- - - -

I am certain this entire situation needs more, careful thought and a redesign 
from the ground up. (Now we encounter the exponential nature of the evil 
'feature creep'! :-P)

Original comment by gru...@gmail.com on 10 Jan 2012 at 1:16

[GoogleCodeExporter]

Where did we get to with this one fellas? My thinking remains unchanged. In 
summary, there need to be no global channel order at all and instead two 
separate settings ...

1. Trainer input channel order (since it depends what radio is used as the 
slave)
2. Model receiver channel order ... from which the template system will draw.
3. Perhaps a global "Default RX Ch Ord" for the above two -- especially no.2 -- 
to default to.

No.2 requires an EEPROM data format addition, of course.

Original comment by gru...@gmail.com on 3 Apr 2012 at 7:18