Initial value for gvars not working or missleading in companion9x

[GoogleCodeExporter]

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

What is your open9x FW version?
r1855

What is your open9x EEPROM version?
212-1

What steps will reproduce the problem?
1. Open companion9x and open model settings
2. Go to Phases tab and enter a value of 25 in GVAR1 for example
3. Configure a mix to actually use GVAR1 (I just assigned it to CH08
4. Load this configuration to a real transmitter

What is the expected output? What do you see instead?
The expected output is the initial value set for GVAR1 in CH08.
In TX simulation of companion9x this actually works, but not in the real 
transmitter. So CH08 is 0 on a real transmitter but 25 in simulator. Also the 
entered initial values for GVARS are not visiable in model menu.
So initial values for GVARS is not supported?
Maybe this is not yet implemented but planned?

Please provide any additional information below.
What is confusing are the two value fields in Companion9x for GVAR1 to 5.
I found that actually only the right box with arrows works and the first field 
is ignored. However on the real tx all values are ignored.

Original issue reported on code.google.com by open.20.fsguruh@xoxy.net on 28 Jan 2013 at 7:46

Attachments:

• ModelConfig.jpg

[GoogleCodeExporter]

Played a little bit more and now I understand it better.
There are differences, depending which board type you use. For stock the 
behaviour is different.

I found the initial values in the Curves tab. However this does not match to 
Companion9x, which haven't the gvars in Curves. Maybe an option for the board 
type is needed for Companion9x to proper simulate.

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?

Original comment by open.20.fsguruh@xoxy.net on 29 Jan 2013 at 4:58

[GoogleCodeExporter]

Why did you post this issue to open9x? It seems to me it is a companion9x issue!

Original comment by bson...@gmail.com on 2 Feb 2013 at 12:31

[GoogleCodeExporter]

For sure is a companion one, also the issue is on stock in which GVAR name is 
not hidden...

Original comment by romolo.m...@gmail.com on 2 Feb 2013 at 12:57

[GoogleCodeExporter]

Yes I agree it is a companio9x issue, but I didn't know in the first post, or 
to be preceise, I thought actually it is a open9x issue.
Can I modified already created issues if I find further information later on? 
(I know I should wait, and analyse better.)
Do you want me to recreate the issue in companion9x?

However with the initial value proposal, is it worth to make a change request 
of it?
That would actually change open9x in a way not to save changed gvars in special 
function, which is very useful for me.

Original comment by open.20.fsguruh@xoxy.net on 2 Feb 2013 at 2:22

[GoogleCodeExporter]

Yes, please, would you open a companion9x issue? Thanks!

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

• Changed state: Invalid

[GoogleCodeExporter]

Will do, what about the gvars change request? I think it is worth, what do you 
think?

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