Hi Matt,
I have a project for a client to add some features and do maintenance on an existing product. It is a battery-powered gas measurement probe. Apart from having some really “challenging” firmware written by several different people the main mission I have is to investigate and optimize the power consumption.
I am unsure how to use JS to measure the power consumption and then relate that to the battery capacity in order to estimate battery life as it is now and then to evaluate each part of the system to see who is the major power consumer.
JS is set to record mAh. If I collect that power consumption in mAh, how do I use it to calculate the possible battery life.
Sorry, bit of a newbie to measuring and optimizing battery systems.
Accurately estimating real-world battery life is not straightforward. Actual battery capacity depends upon temperature and discharge rate. If your target system uses an LDO, you care about total battery charge. If your target system uses a buck or boost converter, you care about total battery energy. The first task is to estimate how much charge or energy is available to your system.
The other side is how much charge/energy your system consumes per unit time. If your device’s states are fairly straightforward (like it wakes up, takes a sensor reading, transmits the sensor reading, then goes to sleep for a predefined interval), you can select the period and compute the charge/energy for the period. You can then find out how many periods until the charge/energy is fully used, which gives you the total battery life.
If the device has different long-term modes (like it sleeps waiting for someone to pick it up), you may need to create a slightly more complicated model. You then need to estimate how often the device is in each of these modes, usually as a percentage, which allows you to compute average charge/energy consumption. You can then use this to compute battery life.
Joulescope makes it easy to measure all of this behavior, but it does not yet automate any of these calculations.
The device has one basic mode of operation for the majority of its life., it periodically collects data. Then, maybe every month, a user connects to it via BLE and collects the logged data.
If I run the device and monitor with JS multimeter I see an accumulating mAh reading, I am not sure what this means and how it can be used.
Given the device is in a stable mode what is the procedure for measuring its consumption in a way that can be used to estimate the battery life. Just looking for some ballpark estimate at this stage, something that may be used as a baseline when making changes to the frimware.
Sorry to be so lacking in knowledge about this, it is a new area for me to investigate.
You can approach this a few ways. The simplest is to use Joulescope to measure the charge used by a single data collection period. You can record data to a JLS file with Joulescope, and then open up the JLS file. Use dual markers to mark one of your device’s data collection periods with the current signal displayed. The dual markers will show the duration in seconds (t1) and the charge (c1) in either Ah or C. Separately, you can measure the duration (t2) and charge (c2) required for the user data collection.
You can then compute the amount of charge per month:
Many devices tend to have multiple modes of operation that make this more complicated. What happens if the user checks the device every two weeks instead of once a month? What happens if you introduce a different mode of operation? You very quickly end up making models, which I like to do in Python. Many people do the same on paper or Excel.
Battery life estimation might be more complicated than just counting Ah. Typically battery internal impedance will increase at the end of its lifespan and it might not be able to deliver the required current for a specific operation. In your case, data measurement might work, but wireless readout might not, as the voltage drop over a near empty battery is too high to support the increased current for the RF circuitry. BLE does not sound too bad though.