Change request; Make gvars change not permanent on option

[GoogleCodeExporter]

Which board (stock / gruvin9x / sky9x) are you using?
stock

What is your open9x FW version?
r1919

What is your open9x EEPROM version?
212-3

What steps will reproduce the problem?
no problem

What is the expected output? What do you see instead?
I want to make a simple change proposal for the stock board.
Because the adjusting gvars in Custom Function permanently changes the gvars 
there do not really exist an initial value. After first modification in custom 
function there original initial value is changed.
Maybe it is an good idea not to store changed gvars in eeprom. This reduces 
write cycles and gives a possibility of the same initial values after 
repowering. 
Maybe we use the Enable flag in the Custom Functions to configure if the change 
should be permanent or not.
What do you think?

Please provide any additional information below.
Was mentioned in issue 186, but this issue was mainly for companion9x.

Original issue reported on code.google.com by open.20.fsguruh@xoxy.net on 5 Feb 2013 at 5:59

[GoogleCodeExporter]

Comments from the Tx experts? Careful to the flash side of things on the stock 
board! I know it's a nice feature, but if it grows too much (on stock board), 
it will be impossible to fit ...

Original comment by bson...@gmail.com on 5 Feb 2013 at 6:49

[GoogleCodeExporter]

GVARS have firstly been asked to simplify redundant settings, especially with 
complex wings. For example, the differential features of a quadroflap wing 
becomes very convenient with a GVAR, instead of 4 separate differential rates 
(that all have the some value). It is the same with other features that need 
global setting.
In this way, GVAR have systematically an original value, and inflight adjusting 
are used only to slightly modify this value.
So, it is very important to save the adjusted value of GVAR !

I'm sorry, but I don't see the interest of forgetting the GVAR setting when 
powering off the radio.

Original comment by f.ague...@wanadoo.fr on 5 Feb 2013 at 9:40

[GoogleCodeExporter]

I see additionally a possibility to reuse a CH10 to CH15 as a replacement for a 
variable. However I fear the often write cycles to the EEPROM as well.
I am still the opinion, it is worth to spend the bit, maybe depending if one is 
still free. 
I do not doubt, it is useful to store it, it is just the additional option not 
to do it, and in this case a screen message would not be necessary as well, 
because the gvars are used as variable (like a misused CH10 to CH15). A better 
name for the current implementation is a constant.
Of course CH10 to CH15 can be used for variable purpose, but it lacks the 
possiblity of an initial value and the combination, where it could be used 
(expo; diff; ...)

Original comment by open.20.fsguruh@xoxy.net on 6 Feb 2013 at 5:53

[GoogleCodeExporter]

More explanation needed. I don't see the purpose of the requested mod. And 
again I cannot see it on stock!

Original comment by bson...@gmail.com on 6 Feb 2013 at 8:33

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

No more arguments from my side. Maybe not worth doing it...
Anybody else having votes?

Original comment by open.20.fsguruh@xoxy.net on 6 Feb 2013 at 8:44

[GoogleCodeExporter]

I think it's at the opposite to what I had in mind when adding the feature ;)

Original comment by bson...@gmail.com on 6 Feb 2013 at 8:50

• Changed state: WontFix