Trainer SW in FUNC SWITCHES messed up

[GoogleCodeExporter]

What Version of the firmware are you running?

Find this by entering the global menu using [LEFT-LONG], then advance to
Menu 3 - VERSION. * Please record at least the SVN data, E.G: "trunk-r38"

*SVN:frsky-r1384
VERS:v1.2-gabo
DATE:2011-12-27
TIME:22:10:56

What steps will reproduce the problem?
1.under function switches the trainer switches does not correspond to real 
AIL,THR,ELE,RUD sticks

What is the expected output? What do you see instead?
when I set function switch Trainer AIL, have trainer input on AIL source. 
ELE to ELE and so on.

What version of the product are you using? On what operating system?
g9x STD SPKR r1384

Please provide any additional information below.
I think it's only cosmetic issue of renaming Trainer YYY switches in this way: 
change Trainer AIL to Trainer RUD
change Trainer THR to Trainer ELE
change Trainer RUD to Trainer AIL
change Trainer ELE to Trainer THR
I try to change the stick modes, but the result was identical.

Original issue reported on code.google.com by adri...@gmail.com on 29 Dec 2011 at 10:08

[GoogleCodeExporter]

Ok will be fixed tomorrow

Original comment by bson...@gmail.com on 29 Dec 2011 at 10:21

• Changed state: Started

[GoogleCodeExporter]

Careful with this. It can get confusing. On the TRAINER screen, we display the 
labels AIL/ELE/THR/RUD in the order of the RECEIVER output channels (as 
selected in SETUP, EG. AETR for me) even though their actual meaning is the 
stick function being replaced by the incoming trainer PPM signal.

Obviously, the Function Switches "Trainer AIL/ELE/THR/RUD" should map to the 
stick function, according tot he stick mode selection and not the receiver 
channel numbers.

Bertrand ... I tested this once and I thought it was OK. Apologies for missing 
it. We'll need to patch the frsky release version with the fix, of course.

Original comment by gru...@gmail.com on 30 Dec 2011 at 2:20

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 30 Dec 2011 at 2:20

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

If confirmed, the fix will be simple in the stable branch.
But Right now I think I will kick a little bit in this stupid conceptual
model in trunk.
Bertrand.

Original comment by bson...@gmail.com on 30 Dec 2011 at 7:50

[GoogleCodeExporter]

I wish I had enough French in me to have any idea what you meant by the last 
sentence, my dear friend. :-D

Let it never be said that these indelible Google comments never contained great 
humour. (Or else! :-P)

Original comment by gru...@gmail.com on 30 Dec 2011 at 8:40

[GoogleCodeExporter]

I meant that 1=left-stick-horizontal, 2=left-stick-vertical ... has no sense. 
Everything is lost if the user changes the Tx mode. So wrong conceptual model.

Thomas changed his mind in th9x and adpoted 1=RUD 2=ELE 3=THR 4=AIL. Much 
better in my opinion. I did the same in companion9x. Now gruvin9x if you have 
no objection of course!

Original comment by bson...@gmail.com on 30 Dec 2011 at 9:02

[GoogleCodeExporter]

What? But that's already taken care of in the receiver channel order, which is 
very important to maintain. Different brand receivers have different labelling 
and channel usage. Therefore, their trainer output channel order matches their 
receiver channel order. So it DOES make sense. It does NOT make sense to have 
is fixed to any one particular order, because that suits only some people.

Original comment by gru...@gmail.com on 31 Dec 2011 at 2:36

[GoogleCodeExporter]

No, the order will not change (and therefore it will not be visible on the 
radio). Only the memory meaning of 1, 2, 3, 4 will change, allowing us to 
change the Tx mode without messing all mixers / expos / everything. 

Original comment by bson...@gmail.com on 31 Dec 2011 at 8:08

[GoogleCodeExporter]

Is that last comment limited to the trainer sw function or are you suggesting a 
new way to refer to the four main channels throughout the rest of the system, 
in the future?

Original comment by gru...@gmail.com on 2 Jan 2012 at 3:57

[GoogleCodeExporter]

Right, but in trunk only. In stable version I will do the minimal change.

Original comment by bson...@gmail.com on 2 Jan 2012 at 9:02

[GoogleCodeExporter]

OK. I'll have to take your word for it. Hmmm ... Can you point me to a specific 
example of code where this issue exists?

All I know is that terminology (wording) such as, "left stick vertical" is 
intended _only_ for cases where the exact physical stick needs to be 
referenced. As far as I can think right now, the only time that is ever needed 
is in the electronic circuit schematics. I cannot think of a case where we 
would want to refer to a stick in this physical manner in user menus. I can 
imagine it might make sense somewhere in source code comments, talking about 
mode definitions for example. But that's completely different.

Original comment by gru...@gmail.com on 3 Apr 2012 at 6:57

[GoogleCodeExporter]

Is this issue still outstanding?

Original comment by gru...@gmail.com on 31 May 2012 at 10:26

[GoogleCodeExporter]

This is to be tested (in the Func Switches screen). Here is the line where
a fix would need to be applied:

if (!s_noStickInputs && (isFunctionActive(FUNC_TRAINER) ||
isFunctionActive(FUNC_TRAINER_RUD+i)))

Perhaps needs to be: isFunctionActive(FUNC_TRAINER_RUD+CONVERT_MODE(i+1)-1)

Original comment by bson...@gmail.com on 31 May 2012 at 4:24

[GoogleCodeExporter]

Pass. I don't understand. I'm closing this issue. It doesn't cause me any 
bother.

Original comment by gru...@gmail.com on 1 Jun 2012 at 12:16

• Changed state: WontFix