Open GoogleCodeExporter opened 9 years ago
Bertrand has mentioned this feature in his "Can I haz Money please" thread
http://openrcforums.com/forum/viewtopic.php?f=92&t=4476
This issue is a big deal for me, so I'm willing to pay USD 100.00 for it.
This offer is registered on FreedomSponsors
(http://www.freedomsponsors.org/core/issue/380/subtrims-per-flight-mode).
If you solve it (according to the acceptance criteria described there), please
register on FreedomSponsors and mark it as resolved there
I'll then check it out and gladly pay up!
Oh, and if anyone else also wants throw in a few bucks on this, you should
check out FreedomSponsors!
Original comment by TilmanBa...@gmail.com
on 29 Oct 2013 at 1:31
But why don't you use the curves on outputs?
Original comment by bson...@gmail.com
on 29 Oct 2013 at 1:55
And the camber being a control order, IMO it should be better done in the mixer
(or even better in the inputs once the dev branch is out)
Original comment by bernet.a...@gmail.com
on 29 Oct 2013 at 1:59
I thought about that a long time. I can not get this working with any
reasonable complexity in mixes. And never really precise
For simple setups, it's quite easy to add a camber null-line high mix and add
that to all servos with the required amount or curves.
But it's dead simple to do that with sub-trims.
I did not believe it was necessary, but discussion with a few f3f pilots and my
own experiments convinced me.
Original comment by TilmanBa...@gmail.com
on 29 Oct 2013 at 2:21
We discussed this in this thread.
http://www.barcs.co.uk/forums/topic/3944-frsky-taranis-the-ultimate-glider-radio
/?p=111303
The discussion goes over a few pages and gets at times quite heated. :)
Since what you really want is to just move the neutral position of the servos
around, it's dead easy to do that on the output channel.
And it's insanely complex and still not really cleanly doable in mixes. I mean
you would waste four curves for this, and it would still be very hard to adjust.
Original comment by TilmanBa...@gmail.com
on 29 Oct 2013 at 2:37
I have got 8 flight modes on my glider contest setup and it is really hard to
make adjustments to the trailing edge of the wing.
If you have ever used the Jeti, you will know that having a flight mode trim
screen really just makes the whole thing far easier.
Original comment by tom.sati...@googlemail.com
on 29 Oct 2013 at 2:59
How would you see this?
A value as it is right now (which would be the reference value). Then if you
press [Enter Long] on this value, it opens a new screen with deltas associated
to each phase.
Right?
Original comment by bson...@gmail.com
on 29 Oct 2013 at 3:05
This is how I imagined it.
Original comment by TilmanBa...@gmail.com
on 29 Oct 2013 at 3:07
I still don't understand why it's so complicated to do in the mixes.
Changing subtrim does the same as adding just a simple MAX line as the last
mixer line on the servo. The percentage on that MAX line can be linked to a
GVAR, and you then get just the same thing.
Original comment by bernet.a...@gmail.com
on 29 Oct 2013 at 11:17
With one mixer entry per servo per flight mode. And a lot of fine trimming in
each. Perhaps.
There are not enough GVAR to waste them like that.
Even if mixes where touring complete, I don't think this is how I would want to
maintain my mixes. :)
Just imagine it like normal trims, which are applied to the inputs. They have a
value per flight mode.
Why not the same for subtrims?
Original comment by TilmanBa...@gmail.com
on 29 Oct 2013 at 11:55
32 channels x 3 values each channel (limits + subtrim) * 9 FM = a lot of memory
wasted for each model. but even just 32 * 9 is a lot of space....
Original comment by romolo.m...@gmail.com
on 30 Oct 2013 at 12:29
No, only 1 mix and 1 gvar per servo. Set gvar values for each mode like you'd
do with the subtrim. Next FW has 9 gvars.
Subtrim is supposed to be mechanical only.
BTW normally if your limits and subtrim are set correctly you should not need a
gvar per servo, only one for each unrelated pair of controls...
Original comment by bernet.a...@gmail.com
on 30 Oct 2013 at 3:46
What would be the range of the delta associated to each phase?
[-5%:+5%] => 4bits
to be multiplied by 32*9 = 144bytes per model
Original comment by bson...@gmail.com
on 30 Oct 2013 at 7:17
on my setup I have used all 5 GVARs and and 55 mixer lines.
I used GVARS for:
aileron travel
aileron differential
flap travel (with aileron input)
flap differential
CAR (aileron to rudder mix).
because you can't change the settings in each flight mode (like a normal radio)
you have to use gvars.
Nearly all the rest of the mixer lines are because you can't change setttings
in each flight mode or have flap settings for each flight mode. E.g I have
three different "snap flap" mixer lines in a high mix, so I can have different
flight mode settings for snap flap.
I have quite a few lines for camber/reflex on the trailing edge of the wing,
because single high mix inputs don't product satisfactory results. You have to
use a separate MAX value for ailerons and a separate one for flaps for each
flight mode.
I imagine a flight mode trim screen would look like the GVAR screen (it's like
this in the Jeti TX). Almost exactly the same. I think you only need to provide
the function for say the first 8 servos, if memory is a problem.
Original comment by tom.sati...@googlemail.com
on 30 Oct 2013 at 9:09
I keep forgetting that all model memory is static.
First eight channels sounds like a reasonable compromise to me.
How much constrained are we with RAM on Taranis and Sky9X?
Original comment by TilmanBa...@gmail.com
on 30 Oct 2013 at 12:11
Well if you don't need a Lua interpreter in your Tx, you have plenty of RAM!
:)
Original comment by bson...@gmail.com
on 30 Oct 2013 at 12:47
But still not so rich in eeprom: especially on taranis
Original comment by romolo.m...@gmail.com
on 30 Oct 2013 at 12:49
I was also thinking about that.
Right now Taranis treats EEPROM the same way the 9x does. With n number of
model memory slots.
But we have a massive mass storage device attached, the SD card.
Why not reduce the number of slots to one. And replace the model selection
screen with one that browses the SD card. And and once you select a entry from
the card it swaps them into eeprom.
Obviously this is a bit off-topic for this feature request. But I always wanted
to bring that up.
Fork this into a new issue?
Original comment by TilmanBa...@gmail.com
on 30 Oct 2013 at 12:53
I don't know how you did the programming for your 8 flight modes. But have a
look at this video. It illustrates my recommended way of doing this kind of
mix. http://www.youtube.com/watch?v=NxCIIyq6Eig
It may serve as imspiration.
Original comment by h.b.jen...@gmail.com
on 3 Nov 2013 at 6:30
Sorry, but I don't understand :
- how 55 mixes could be used for a F3F glider ? As a Gvar can have one
different value per flight mode (except with 9x stock board), there's no need
to have more than one mix per servo to change camber, snap-flap or
differential's rate if a Gvar is used instead of the rate.
- with correct setting-up of servos ("=" option for linearity, sub-trim and
throw set for +/-100% displacement before applying mixing rates), you should
have no problem to have perfect alignement with camber or snap-flap.
To my opinion, individual subtrims for each servo per flight mode is not the
right way to solve this issue.
Original comment by f.ague...@wanadoo.fr
on 4 Nov 2013 at 8:44
I'm not flying f3f, i'm flying f3b. I've stated above what I use my gvars for.
I would need about 10 gvars to be honest. Everyting would be miles simpler if
you could just have a different weight/diff setting for each flight mode, which
you can't. What do flight modes actually do in opentx? basically nothing other
than let you have different trims and switch mixers on and off (which you could
do with custom switches anyway).
It DOESN'T WORK to use one gvar or one value to change trailing edge of the
wing. The servos don't line up evenly across the wing. If you could just
change the weight setting in each flight mode that would even work.
opentx has the worst flight modes of any tx I have used.
Original comment by tom.sati...@googlemail.com
on 16 Nov 2013 at 5:27
Post your EEPROM, I'm sure someone will be able to come up with
simplifications.
Still sure that one GVAR can be used for trailing edge adjustment if the rest
of the programming is done right.
Original comment by bernet.a...@gmail.com
on 20 Nov 2013 at 11:37
Original issue reported on code.google.com by
TilmanBa...@gmail.com
on 29 Oct 2013 at 1:29