In this post we’ll be looking at the behaviour of the battery as it discharges, and how measuring the voltage provided by the LiPo can be used as a gauge — i.e. an estimate of its fullness level.

When dealing with LiPo battery, it’s important to have an understanding of their general characteristics (including precautions to take). There are a few good tutorials on the web; such as Adafruit’s here.

For this experiment I developed a short program that pushes LimiFrog in an extreme (worst case) usage scenario, where power consumption is maximized. The greatest contributor to power consumption is the OLED display. A specificity of OLED displays is that power consumption depends on the image contents. Specifically, a pixel is composed of  3 red, green and blue sub-pixels, and the contribution to power consumption of each pixel depends on the intensity of its red, green and blue contents. A black pixel consumes very little power, a bright pixel consumes more power than a dimmer pixel, and a white pixel is the worst case situation with all three red, green and blue sub-pixels being 100% on.


Shifting pattern of vivid colors diplayed on OLED

The program I built consists of having the STM32 constantly running at full speed and getting the OLED to display a shifting pattern of vivid colours.

As soon as the pattern is displayed, it is overwritten with a new one. The latter is created in the same way as the former, only each colour is shifted by one position. Although that’s not the absolute worst case in terms of OLED power consumption (a pure white screen would be), it’s not far.

In addition , every minute, a measure of the voltage supplied by the battery is taken by the STM32. The result is very briefly displayed on screen and is logged into an ASCII file on the file system of LimiFrog. Voltage-Screen

When the experiment is finished (battery discharged), it is then possible to connect LimiFrog to a PC through USB, copy the (.csv) log file and look at the evolution of the battery voltage over time — perhaps displaying it as a curve using Excel or your favorite spreadsheet. If you’re a lucky owner of LimiFrog and whant to try it by yourself, the code is here on GitHub.

In case you’re curious about it, measuring the battery voltage is catered for on the LimiFrog board by the following circuit. The battery voltage (up to 4.2V) is scaled down by a resistor bridge to fit into the 0-3V range of the STM32 analog-to-digital converter. The “foot” of the resistor bridge is connected to a GPIO so that it gets connected to ground under software control only when a measurement needs to be taken, to conserve power. This GPIO is simply set up as open-drain output when needed, and stays in high impedance at all other times.


So, starting from a fully charged battery, the expected behavior of the LiPo is to start supplying a 4.2V voltage, quickly drop to about 3.7-3.6V and stay around this value for most of its lifetime, to then sharply drop when the battery becomes almost empty. Below 3V a LiPo battery can be considered empty. Since it is dangerous to over-discharge a LiPo battery, the battery management IC present in LimiFrog (LTC3553) cuts power when it detects the battery voltage has reached 3V.

And this is what I measure with LimiFrog’s battery, rated at 500mA.h :


A few interesting observations can be made :

  • the fully charged voltage is about 4.1V rather than 4.2V. I suspect this is due to the fact the batteries I’ve used are not new and have been stored on a shelf for over a year. However, given the battery voltage does not stay for long above 4V (as confirmed below), this is no big deal in terms of missing battery life.
  • the LTC3553 does indeed cut power at 3V (phew!)
  • the results appear to be replicable (although more runs would help quantify this preciely). This means it looks possible to build a reliable relationship (look-up table or other) between measured battery voltage and battery fullness (level in %). For example, an application could periodically check the battery voltage level (say, every 1mn) and warn the user when there’s only 10% “fuel” left.
  • The life time obtained with this “extreme worst case” is a little over 5 hours and 30 minutes. This is in line with the experience I have of continuously displaying more “real-life” photos and image, where battery lifetime was over 10 hours. This also means applications that need to display stuff only occasionally can easily enjoy several days of lifetime, even weeks if display usage is sparse enough.
    Time permitting, I will conduct more experiments with real-life image scenrios and post the results.


After the publication of this post, I have been contacted by Nicolas of He had done something similar to assess the remaining lifetime of batteries for a robot he has designed (impressive work, by the way ! ), plus had gone to the step of expressing remaining battery lifetime as a function of measured voltage. He offered to perform that step on LimiFrog’s results too — here’s what he did :
Based on my measurement file and knowing the general form of a battery discharge equation, he was able (using Maple) to identify the parameters of the equation that best fit the measured discharge curve. Then, inverting the fitted curve, he was able to relate battery voltage to remaining lifetime of the battery for the particular model I am using.

And this is the result :


As expected for a Lipo battery, voltage remains above 3.6V for most of its lifetime and the battery can be considered dead at 3.4V or so — less than 5% of its full capacity are still available before power is cut off to avoid over-discharge hazard.

ShareTweet about this on TwitterShare on FacebookEmail this to someoneShare on Google+Share on LinkedInPin on Pinterest