Current sensor calibration/erroneus voltage readings

[GoogleCodeExporter]

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

Taranis.

What is your openTx FW version?

What is your openTx EEPROM version?

What steps will reproduce the problem?
1.Connect FAS-40 current sensor.
2. Expect accurate current/capacity readouts
3. Get 0.5A offset/-10% capacity reading.

What is the expected output? What do you see instead?
See above.
Also, sometimes the low voltage alarm is triggered, although the pack has OK 
voltage. See below.

Please provide any additional information below.

I recently purchased a FAS-40 of neccessity, and operate it on my Quad using 
the Vario as adapter.
It generally works fine, but I have 2 problems:

The first is a -0.5A offset of the current reading. According to my WattsUp, my 
Quad needs 0.5A on the ground, but the FAS-40 displays 0A. During flight, it 
also shows 0.5A less than what the WattsUp reads. This translates in a -10% 
error in the capacity reading after a typical flight.
My charger agrees on the capacity my WattsUp reads, so I assume the error is on 
the side of the FAS-40.

Next problem are intermittent low voltage alarms, also when my battery is 
clearly above the threshold.
This starts right after connecting the flight pack,when the alarm goes off the 
first time.
During flight I also get it once or twice, so that I had to do a workaround:
Two programmable switches are triggered by the LVA, but one with a 3sec delay.
These two programmable switches together (AND) trigger a third programmable 
switch, which triggers the voice alert.
This means, that a short wrong alarm will not trigger the voice alert, only 
when the low voltage condition lasts longer than the delay, it will be 
triggered.

This means, it would be ideal to have these additional options in the TX menu:
Values to compensate "offset" and "linear faults" for the current reading 
should be allowed to be entered.
One should be allowed to enter a time an alarm-triggering condition must be 
present to actually trigger the alarm, so that short, erroneous readings will 
not trigger it.

Original issue reported on code.google.com by extremf...@gmx.de on 1 Nov 2013 at 5:15

• Merged into: #166

[GoogleCodeExporter]

better to ask frsky to correct the error in the sensor than adding more setting 
in opentx

Original comment by romolo.m...@gmail.com on 4 Nov 2013 at 10:06

[GoogleCodeExporter]

Original comment by bernet.a...@gmail.com on 25 Nov 2013 at 5:11

• Changed state: Duplicate
• Added labels: Type-Enhancement
• Removed labels: Type-Defect