search

vinodstanur / open9x

Automatically exported from code.google.com/p/open9x
0 stars 0 forks source link

Gvars should be usable with negative and positive sign for weight and offset #194

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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 feature request

What is the expected output? What do you see instead?
Currently gvars could be selected in weigth, offset and for differenciate.
It is often the case the same constant, variable is used on several channel and 
gvars is an elegant way to prevent changing the same value for each channel 
separately. 
Unfortunately it depends on the combination, if the constant is needed on 
positive or negative side. An inverted output does not the job, because other 
elements may be added as well. See picture below for an example. Two constants 
should be enough, but I needed 4.

Please provide any additional information below.
I feel a little bit sorry to have su much ideas in the moment. I promise, this 
is my last request for longer...

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

Attachments:

GoogleCodeExporter commented 8 years ago 
There's two other elegant ways to solve this issue (which are two good 
programming practices to keep in mind :) ) :

1/ invert aileron source on CH05 (with an sense inversion on CH05 in ouput / 
limits menu), so both Thr sources can have the same sense in mix.

2/ use a dedicated virtual channel that aggregate sources to make a function, 
which is used by physical channels :
CH04 +100% Ail
  += +100% CH10
CH05 100% Ail
  += -100% CH10
CH10 +50% Thr
  += -35% Thr

Original comment by f.ague...@wanadoo.fr on 6 Feb 2013 at 7:22

GoogleCodeExporter commented 8 years ago 
I forgot to say that the second good pratice is very powerfull and space-saving 
with flight phases.
Examples : 
https://code.google.com/p/open9x/downloads/detail?name=Open9x_AdvancedGliders.zi
p

Original comment by f.ague...@wanadoo.fr on 6 Feb 2013 at 7:25

GoogleCodeExporter commented 8 years ago 
Right. I cannot introduce negative GVARS everywhere on stock, there is a 
problem of flash and RAM. Today we are too short. I will implement it though on 
all ARM flavors.

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

GoogleCodeExporter commented 8 years ago

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

GoogleCodeExporter commented 8 years ago 
This memory limitation on the Atmel is hard. Do I understand it correctly. 
Currently a byte is used for weight, offset and diff. Because only values from 
-125 to 125 is used, there a still 5 positions free, which are used for gvar1 
to gvar5 currently. To use -gvar1 to -gvar5 additional 5 positions are needed 
and of course we do not spend 3 additional bytes. 
-128 = gvar1; -127 = gvar2; -126 = gvar3; 126 = gvar4; 127 = gvar5;

Following proposal for stock:

Proposal 1:
-----------
How difficuilt would be the following implementation:
We limit the values from -123 to 123 which would give 4 additional positions:
-128 = gvar1; -127 = gvar2; -126 = gvar3; -125 = -gvar1; -124 = -gvar2;
124 = -gvar3; 125 = -gvar4; 126 = gvar4; 127 = gvar5
--> only gvar1 to gvar4 could be used negativ, but this should be enough

Proposal 2:
-----------
A other compromise could be to actually spend 1 additional byte per mix line
We split the 8 bits following: 1 extension bit for weight; 1 extension bit for 
offset; 6 bits still free for other things
the diff offset would be done according the first proposal, because more than 
+-100 for differenciate is very crazy anyway.

The implementaton would be following:
weight value is the current byte + the 1 extra bit of the new byte --> -256 to 
255 values are not possible. We allow just -250 to 250 is allowed. 
-256 -> gvar1; -255 -> gvar2; .. -252 -> gvar5; -251 -> gvar6 (if you want ;-)
251 -> -gvar1; 252 -> -gvar2; 255 -> -gvar5

The same is applied to offset;
Results would be:
extented range for weight and offset; now from -250 to 250 which is usefull 
anyway
-+gvar selection still in differenciate possible; 
Slightly reduced range in differenciate from -123 to 123 
6 extra bits still free for other nice features...

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

GoogleCodeExporter commented 8 years ago 
One extra byte per Mix is impossible, it means 32bytes / model and 32bytes RAM!
But I am implementing another solution with 2 spare bits in the MixData. It 
should be ok tonight.

Original comment by bson...@gmail.com on 6 Feb 2013 at 7:31

GoogleCodeExporter commented 8 years ago

Original comment by bson...@gmail.com on 6 Feb 2013 at 7:32

GoogleCodeExporter commented 8 years ago 
Done. On all boards (stock=170bytes flash used)

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

GoogleCodeExporter commented 8 years ago 
Great, it look alright, but didn't work :-(
The mix menu is OK, but the negative gvar multiplication is not done, maybe it 
tooks the wrong gvar? I will test further. 
OK found it, instead of -gvar1 it tooks -gvar3 and instead of -gvar2 it tooks 
-gvar4.
Index problem?

What do you think about my suggestion to extend the weight offset to -250 to 
250 + having -+gvars? Should be the same cost of EEPROM, just the 2 bits.

Original comment by open.20.fsguruh@xoxy.net on 7 Feb 2013 at 9:57

GoogleCodeExporter commented 8 years ago

Original comment by bson...@gmail.com on 7 Feb 2013 at 10:06

GoogleCodeExporter commented 8 years ago 
Hi, found the fault in open9x.cpp in line 1083:
      idx = 1-idx;
should be
      idx = -1-idx;
just one character...

Maybe the same for the other compiles...

Did you extend the value range to -500 to 500 for weight? Possibly forgotten in 
menu?

Original comment by open.20.fsguruh@xoxy.net on 7 Feb 2013 at 10:49

GoogleCodeExporter commented 8 years ago

Original comment by bson...@gmail.com on 8 Feb 2013 at 11:18