Closed GoogleCodeExporter closed 9 years ago
Ok will be fixed tomorrow
Original comment by bson...@gmail.com
on 29 Dec 2011 at 10:21
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
Original comment by gru...@gmail.com
on 30 Dec 2011 at 2:20
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
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
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
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
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
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
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
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
Is this issue still outstanding?
Original comment by gru...@gmail.com
on 31 May 2012 at 10:26
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
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
Original issue reported on code.google.com by
adri...@gmail.com
on 29 Dec 2011 at 10:08