sylvandb / gruvin9x

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

Low bat alarm doesn't sound when voltage is below 4.9V (first noted on frsky/stock board.) #95

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Flash a stock board with 'FriSky' public release r1413 (std-speaker)
2. Note that key beeps etc work but low battery alarm (even though inverse and 
flashing) does not sound through the beeper.

Original issue reported on code.google.com by gru...@gmail.com on 16 Mar 2012 at 2:17

GoogleCodeExporter commented 8 years ago
Addendum: The above was with the board being powered from the MCU programmer, 
display at 4.8V. Oddly, when we connected the main batteries, the alarm started 
working. Hmmm.

Original comment by gru...@gmail.com on 16 Mar 2012 at 4:24

GoogleCodeExporter commented 8 years ago
Have a look around gruvin9x.cpp:1696

Original comment by bson...@gmail.com on 2 Apr 2012 at 8:13

GoogleCodeExporter commented 8 years ago
... && g_vbat100mV>49

WTF? That's being removed right now. Must be some hangover from the days before 
bandgap checking, which is another thing I must get on to for the stock board.

Ironically however, there was another cause for this specific fault. The 
transmitter was being powered by the gProg programmer at the time, which meant 
that the separate 5V regulator for the stock piezo beeper had no power. Hence, 
no sound. but this is good spotting anyhow.

Original comment by gru...@gmail.com on 3 Apr 2012 at 4:20

GoogleCodeExporter commented 8 years ago
No -- I was wrong about the stock beeper not getting power when the switch is 
off. It still worked when I tested it. 

Investigations in the frsky branch revealed that the intention of the >49 code 
was to silence the alarm when being powered off a Flash programmer. The 
inactivity alarm is likewise silenced. I can't recall, but this was probably 
some of my not-so-brilliant coding.

A better approach would be to also check for !SLAVE_MODE, as well as the 4.9V 
lower threshold. In this way the "badness" of this code for genuine flying 
conditions will be minimised to occasions when a trainer is available to take 
back control of the model.

I'm effecting this in code now. I'll test it in both frsky and trunk and if my 
theory works out correctly, I'll generate a maintenance release -- also 
including the BG averaging I've been meaning to do for a long time.

Original comment by gru...@gmail.com on 3 Apr 2012 at 4:44

GoogleCodeExporter commented 8 years ago

Original comment by gru...@gmail.com on 3 Apr 2012 at 4:53

GoogleCodeExporter commented 8 years ago
Fixed in trunk and also committed as new frsky maintenance release. I won't 
bother announcing it, as it's not really a big deal.

I also added a simple low-pass filter to remove bandgap jitter on the stock 
board as well as improving the efficiency (in terms of CPU clock load/spread) 
for the v4 board bandgap stuff.

Original comment by gru...@gmail.com on 3 Apr 2012 at 6:46