v3 EEPROM EXPO/DR conversion error
GoogleCodeExporter opened this issue · comments
As at r1094, converting v3 EEPROM data fails in EXPO/DR screen
Example ...
Model: Groovy (from r569 attached file)
==============================
EXPO/DR
exp wt sw1 sw2
RUD 50 50% - AIL --- M
ELE 26 45% -> AIL --- M
THR 0 100% <- AIL --- M
AIL 20 60% -> AIL --- M
... and with AIL switched off ...
EXPO/DR
exp wt sw1 sw2
RUD 60 100% - AIL --- H
ELE 60 105% -> AIL --- H
THR 0 100% <- AIL --- H
AIL 60 100% -> AIL --- H
==============================
... gets translated to ...
==============================
EXPO/DR
RUD 0 100 ---
60 100 AIL
ELE 0 100 ---
60 100 AIL
THR
AIL 0 100 ---
60 100 AIL
==============================
As you can see, "AIL" is on the wrong lines (all should move up one on screen)
and the AIL_SW=ON (1st, 3rd & 6ty) lines do not have their correct
corresponding values:50, 26, 20 for expo or their values: 50, 45, 60 for weight.
- - -
Pretty sure this is the last bug, as far as converting from v3 goes. :D
Original issue reported on code.google.com by gru...@gmail.com on 10 Oct 2011 at 8:10
Attachments:
ERRATA: The line ...
ELE 60 105% -> AIL --- H
... should be ...
ELE 60 100% -> AIL --- H
Original comment by gru...@gmail.com on 10 Oct 2011 at 8:15
There's another problem ...
To get this to work right at all, I have to specify a negative switch for the
full rate lines. This should not be necessary. Here's what I have to do to make
it work the same as the old r569 system ...
==============================
EXPO/DR
RUD 50 50 AIL
60 100 !AIL
ELE 26 45 AIL
60 100 !AIL
THR
AIL 20 60 AIL
60 100 !AIL
==============================
This is incorrect, in my view. It should be that the lines with no switch
assigned should be active (like the default setting) if none of the other lines
for that channel are active.
I this could be taken care of using flight modes instead. But without flight
modes being used, it should still work as just a simple EXPO/DR switch, as I
have described.
No?
Original comment by gru...@gmail.com on 10 Oct 2011 at 8:25
Yes, you are right.
Original comment by bson...@gmail.com on 10 Oct 2011 at 9:52
Same bug in companion9x as well.
Original comment by bson...@gmail.com on 10 Oct 2011 at 2:26
It was more complex. Previously the expos were ALL applied in the order they
came. Therefore it was needed to have the default at first and the specific to
a switch, flight phase next.
I have to say that this logic is a report from th9x. It doesn't correspond to
my (and your) logic. I prefer when specific is first and general (default) is
at the end.
Moreover, it should save some us: only one expo will be calculated for a stick.
There could be many before.
More tests needed (should I say ... as for each of my commits)!
Bertrand.
Original comment by bson...@gmail.com on 10 Oct 2011 at 7:40
- Changed state: Fixed
Tested and verified. Well done, again!
Original comment by gru...@gmail.com on 10 Oct 2011 at 9:51
- Changed state: Verified