Batery Voltage calculatin

[GoogleCodeExporter]

What Version of the firmware are you running?

Find this by entering the global menu using [LEFT-LONG], then advance to
Menu 3 - VERSION. * Please record at least the SVN data, E.G: "trunk-r38"

*SVN: frsky-r1269
VERS:V1.2-gabo
DATE:2011-11-27
TIME:01:01:10

What steps will reproduce the problem?
1. show voltage on main display
2. example: it is jumping from 9.9 to 10.2 sometime to 13.3
3.

What is the expected output? What do you see instead?
Stable voltage measuring. for above example 10.1V

What version of the product are you using? On what operating system?

Please provide any additional information below.
Maybe calculation from ER9x will be helpful.
I try to find the code from ER9x, but no success.

Original issue reported on code.google.com by gbir...@gmail.com on 27 Nov 2011 at 11:52

[GoogleCodeExporter]

Sounds like you have one of the few 9X radios with a broken bandgap reference. 
Bertrand has one of those too. At this stage, we have no idea what to do about 
it. Bertrand increases the averaging algorithm to work around the problem but I 
say that's completely pointless and negate the reason for using the bandgap 
reference in the first place. It is supposed to be rock solid. On some chips, 
for goodness knows why, it simply is not.

At this stage, you are one of only two people I know of with this problem. That 
doesn't mean it will be ignored though.

Since you're compiling your own source, it would be helpful if you could 
experiment with the delay figure on line 826 of gruvin9x.c to find a stable 
read-out. [_delay_us(5)]. Hopefully, you won't have to go above 10uS. But keep 
going up until it stabilises. Thanks.

Please let us know your findings by commenting within this issue. If the 
required delay for you seems reasonable, I'll change it for everyone.

Thanks again.

BTW -- this problem is gone entirely on the V4.1 board, since we've added a 
more reliable, external voltage reference chip.

Original comment by gru...@gmail.com on 28 Nov 2011 at 12:25

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have two of them. And I know one man with one more of them. Only for 
statistics.
OK, I try it on booth radios and it looks good with value of 7us. Please commit 
the change for "_delay_us(7)".
It's perfect!

Thanks 

I vote for Vertical progress bar.

Original comment by gbir...@gmail.com on 28 Nov 2011 at 10:13

[GoogleCodeExporter]

Excellent. Thanks!

+1 for the vertical bar. I think that's where Bertrand has settled now anyway. 
All good. :-D

Original comment by gru...@gmail.com on 29 Nov 2011 at 12:43

• Changed state: Fixed

[GoogleCodeExporter]

I will also try this value. At the time all values didn't work. In er9x Mike 
makes now an averaging on the BandGap value itself (many guys reported this 
issue). On my radio, I have an averaging of the voltage, but after the BandGap 
maths are applied. It avoids 2 averaging as it is now in er9x.

Original comment by celine.d...@gmail.com on 29 Nov 2011 at 7:57

[GoogleCodeExporter]

I am strongly against averaging the bandgap. If you have to average it, then 
you've negated the entire reason to have it in the first place. You'd just be 
wasting your (and the MCU's) time for no good reason. I would rather just set a 
constant -- 225 for ATmega64 board, I think. Either that, or junk that radio 
for spare parts and get another one, without a broken ATmega chip.

Original comment by gru...@gmail.com on 29 Nov 2011 at 7:20