Skip to main content

You are here

What is the best way to monitor remaining battery power?

9 posts / 0 new
Last post
PavelE
What is the best way to monitor remaining battery power?

One of my intended uses of Measuring VCC via "bandgap" was to measure properly a remaining power of a single AA battery used in AA board. But the scope is growing ;)

So far I've selected two way to power my WSN/JN setup - AA board or 3xAA Battery holder.

To make things even "easier", it is possible to use completely different battery types - Alkaline and rechargeable (I prefer Eneloop).

Lets collect some opinions....

So far there are two opinions: minimum or none elements or a proper voltage divider.

With more than one battery, a resistor voltage divider is the easiest solution, but I'm a bit concerned about the extra power drain (10kOhm == 330uA), because we should avoid "bad" design.

Another point is how to connect wires (or avoid them). There is no provision for such a direct battery power measurements, AFAIK, on either AA board or JN6, but there is a lot of space and there is one unused pin on FTDI header.

So, expected requirements:

  • flexibility - should support any of mentioned above battery setups
  • minimum wires - if it is permanent/standard solution, why not solder it
  • enough precision (10%??) to identify a dying battery

    "Prior art" - TODO:

  • There is a configurable low voltage check in RF12 library - TODO link
  • TODO - check for JCW blog posts
  • PavelE
    PavelE

    I have at the moment a quick setup:
    = AA board with a single AA cell
    = 1MOhn resistor [just in case] from BATT to unused IRQ on Port1 - see martynj concern
    = a wire from AA board IRQ on Port1 to A1 on JN6
    = Code to measure VCC via reference
    = Code to measure current AA battery voltage against the VCC

    Result: Precision - last digit - about 1% comparing to VDM (3-digit VC130 declared 0.5%)

    PavelE

    @martynj, @jcw

    I really like to use the NC pin (#2) on FTDI header as a special "BATT" connector.
    The idea is to make "automatic" voltage divider for sensing remaining battery power and connect it to a available Analog pin on PIC to be able to measure it.

    It could be protected by a voltage divider on JN6 and the matching resistor on power source side to provide the same range voltage (0.4-0.8V) when on battery power: 1/2 for AA cell , 1/6 for 3xAA block.
    For a "wall power" it is possible to put it to 1.1-1.5V to indicate it.

    Any objections (like you are planning to use this NC pin in nearest future) ?

    martynj

    @PavelE, unfortunately Pin2 is driven by CTS from the FTDI chip on the USB BUB

    PavelE

    @martynj

    CTS is not used right ?
    Also here: "The CTS line isn't used for much with Arduino environment but it can be used to see if a board is plugged in."

    May be I could just cut the line on PCB as I would not be using USB BUB II for anything but JN. This might be not needed if the voltage on CTS is constant and not too high as I could just use it ;)

    What about JL components, any plans to use this pin?

    PavelE

    FYI: Code snippet: https://github.com/PavelNL/CodeSnippets/blob/master/measure_voltage_AAbatt

    Comments are always welcome ;)

    padvinder95

    Don't you run into rollover problems around line 120 of your code?

    byte x1 = vccRead(VCC_READ_DELAY); byte x2 = vccRead(VCC_READ_DELAY); byte x3 = vccRead(VCC_READ_DELAY); byte vccValue = (x1+x2+x3) / 3;

    If bytes x1, x2 and x3 together are more than 255, they will roll over I think? Or does the compiler change the order? If not, you should do byte vccValue = x1/3 + x2/3 + x3/3 (although then you lose some precision.

    PavelE

    @padvinder95
    Agree, this should be as code below, where I've used 'word' to avoid overflow. Fixed.
    But ...
    Just did a short test:
    byte b1 = 253; byte b2 = 255; byte b3 = 254; byte sumb = (b1+b2+b3) / 3; Serial.print("AVERAGE of 253+255+254 should be 254, real is: "); Serial.println( sumb );

    The result was pretty unexpected:
    AVERAGE of 253+255+254 should be 254, real is: 254

    It looks like in compiler there are more type conversions than we know ...

    Premium Drupal Themes by Adaptivethemes