Vario tone range should be based on the range of the vario

[GoogleCodeExporter]

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

What is your open9x FW version? r1761

What is your open9x EEPROM version?213

What steps will reproduce the problem?
1.setup a vario with a 6m/s range and an offset of -3m/s
2.produce vario sounds by either moving your plane or directly simulating the 
signal (connect and use a variable voltage source to the input on your frsky 
telemetry enabled receiver) the vario tone will never result in the maximum 
possible "beep" range even though the full range is being displayed as numeric 
data
3.if you want to have the full audible range, you have to set the vario range 
to 20m/s , which then results in wrong readings for the sink rate

What is the expected output? What do you see instead?
change the vario code in order to allways calculate the full audible range 
based on the defined range of the vario sensor as setup in the telemetry setup 
screens.

Please provide any additional information below.
Thx!

Original issue reported on code.google.com by Raine...@gmail.com on 16 Jan 2013 at 9:13

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 21 Jan 2013 at 2:18

• Changed state: Started

[GoogleCodeExporter]

I have started working on this one. I don't think that the sensor range should 
be used for the vario range. Today the vario range is hardcoded: -10m/s => 
+10m/s.

I am adding 2 new parameters for the vario range. The minimum will go from 
-17m/s to -3m/s and the maximum from +3m/s to +17m/s

No RAM nor EEPROM needed more, only a little bit flash used.

May I ask you which sensor you use and if it's better than the FrSky one?

Original comment by bson...@gmail.com on 21 Jan 2013 at 2:22

[GoogleCodeExporter]

i am using a self built solution using a MS5611 (resolution +-10cm with quite 
some noise)  as the sensor and an arduino pro mini  to produce the analog 
signal to the frsky receiver. the Resolution is better than the frsky one. 
Additionally the calculated altitude will be written via the FRSKY Sensor Hub 
Protocol.

Original comment by Raine...@gmail.com on 21 Jan 2013 at 2:26

[GoogleCodeExporter]

Why don't you calculate the vario directly on the sensor? I plan to add the 
support of this functionality inside open9x

Original comment by bson...@gmail.com on 21 Jan 2013 at 2:34

[GoogleCodeExporter]

I already habe the absolute height and the Lift/Sink rate as variables 
available in my arduino. if there´s a better way to transfer those values back 
vi frsky i would love to do so. 
Currently i map the sink rate between -3 and +3 m/s to a voltage of 0 to 3.2V 
which goes to A2 on the receiver. 
The abvsolute height is being send via the frames with id 0x10 and 0x21 ( event 
though the 0x21 data containing the cm part of the height will not be displayed 
or processed into the lift/sink rate when i choose data as the vario source).

what exactly are yyou planing to implement? a new package type to directly send 
the lift/sink rate? A method to transfer an audio signal created in the arduino 
via the analog signals?

Original comment by Raine...@gmail.com on 21 Jan 2013 at 4:33

[GoogleCodeExporter]

We will soon have an ID for the vario rate. So the calculations may be done on 
the receiver side rather than in the Tx where we have a too small sample rate 
(on altitude values).

Original comment by bson...@gmail.com on 21 Jan 2013 at 4:45

[GoogleCodeExporter]

sounds great. I´d be happy to implement the new id in my code and test it if 
an open9x binary is available.

Original comment by Raine...@gmail.com on 21 Jan 2013 at 4:48

[GoogleCodeExporter]

Are you able to compile open9x and test? I just commited my fix, but didn't 
test anything.

Original comment by bson...@gmail.com on 21 Jan 2013 at 8:36

[GoogleCodeExporter]

no, don´t have a build env here. and i am only using a w7 system right now.
could you send me a build (sky9x,frsky,templates,gvars,autoswitch,dbkeys is 
what i am using right now)

Original comment by Raine...@gmail.com on 21 Jan 2013 at 8:51

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 22 Jan 2013 at 8:16

• Changed state: Fixed