How to estimate battery life for IoT devices

Updated October 2026 with a step-by-step estimate and worked examples.

The increasingly complex world of IoT solutions requires novel approaches to keep the cost and usability at an acceptable level, like using advanced AI algorithms, including machine learning and neural networks running on the “edge”. Smart devices doing as much of the data-heavy lifting as possible can cut down the cost associated with uploading raw data to the cloud and processing it there. But since many of the edge devices are powered by batteries, how does this affect their battery life?

This article helps to build an understanding of how the battery life of a device is affected by various factors.

How to estimate battery life in four steps

A battery-powered device spends most of its time asleep and wakes for short bursts to sense, think and transmit. Its battery life is the usable battery capacity divided by its average current. Everything else is bookkeeping.

1. List the states. For example: sleep, wake and measure, process, transmit. Note the current in each from the datasheets, or better, from a measurement with a power analyser.
2. Note how long each state lasts per cycle, and how often the cycle repeats.
3. Average the current: I_avg = (I₁·t₁ + I₂·t₂ + …) / cycle time.
4. Divide usable capacity by I_avg. Usable is less than the label: derate by 20–30% for the regulator, the cut-off voltage, cold and self-discharge.

The figures in the examples below are typical values chosen to show the method, not measurements of a particular product. Replace them with your own.

Example 1: a sensor that uploads over Wi-Fi every 10 minutes

The microcontroller sleeps at 10 µA. Every 10 minutes it wakes, joins the access point, sends a reading and goes back to sleep; that takes about 2 seconds at an average of 100 mA. Per 600-second cycle: 100 mA × 2 s = 200 mA·s awake, plus 0.01 mA × 598 s ≈ 6 mA·s asleep. The average is 206 / 600 ≈ 0.34 mA. Two AA alkaline cells give about 2,500 mAh, or 1,750 mAh after derating, so the sensor runs 1,750 / 0.34 ≈ 5,100 hours: about seven months.

Upload once an hour instead and the average falls to 0.066 mA, which gives about three years. At that rate the 10 µA sleep current is already 15% of the budget, so the next gain comes from the sleep circuit, not the radio. A Bluetooth Low Energy or Zigbee radio sends the same reading in a few milliseconds instead of two seconds, which is why coin-cell sensors use those radios and not Wi-Fi.

Example 2: always-on keyword spotting or tiny vision

Always-on inference never sleeps, so its active current is the whole budget. A microcontroller that listens for a wake word at 2 mA runs 1,750 / 2 ≈ 875 hours on two AA cells: about five weeks. On a CR2032 coin cell (about 220 mAh, less under load) it lasts four days. Continuous inference reaches months only on parts that run the model below about 100 µA, or with a low-power trigger such as a voice-activity detector, a PIR sensor or an accelerometer that wakes the inference core only when something happens.

Example 3: a camera that wakes on motion

This is how our Tokay Lite camera is meant to work. Assume the camera sleeps at 20 µA with its PIR sensor armed. Each motion event wakes it for 5 seconds at 150 mA to take a photo, run the model and send the result over Wi-Fi. With 20 events a day: 20 × 5 s × 150 mA = 15,000 mA·s ≈ 4.2 mAh, plus 0.02 mA × 24 h ≈ 0.5 mAh asleep, for 4.7 mAh per day. A 3,000 mAh LiPo derated to 2,400 mAh lasts about 500 days. Double the events and you halve the life, which is why the trigger matters more than the battery size. A solar roof camera we built on the same platform runs about six months on one charge through a winter under snow.

Battery – powered device operation lifecycle

To start, a basic understanding of low-power device operation is required.

An IoT battery product will most likely reside in the lowest power consumption state possible most of the time to maximize battery life. This means turning off any communication interfaces, sensors, and data processing systems. This state is often referred to as the standby or power-down state.

A purely wakeup-based system will most likely reside in this state and keep a minimum amount of components active. The simplest example is a button-based wake-up when the device’s power is switched on by a button press, so only a small portion of the circuit consumes power to monitor the button press. A Real Time Clock can be kept running to allow time-based wakeups, either periodically, or at a specified time.

Quite often, however, we need to monitor the external environment continuously, reacting to sudden changes or conditions and acting on them. This leads us to the always-on concept, which usually means that a bigger portion of the device is awake all the time. For example, an always-on temperature sensor can wake up a system when the temperature reaches a critical level to send an alert to the cloud. Or a smart speaker with an always-on microphone and audio processor is constantly powered on to detect and classify “wake words”.

In the always-on cases, the designer should pay special attention to the power consumption of the always-on components, as they are likely to define the battery life for the whole product.

Multi-level sensing

Sometimes the active power consumption of components that are supposed to work in always-on mode is too high to satisfy battery life requirements. In that case, a multi-level sensing approach can be taken. For example, instead of keeping the GPS receiver on a location-tracking device, why not just use a low-power accelerometer so that system power consumption is ~1000x less when the tracker is not in motion? Or, why run a power-hungry AI camera to detect objects when there are no objects in the scene if you can switch it on with a proximity sensor or light detector?

Major contributors to battery life for IoT battery devices

An embedded device is a complex beast with lots of components that consume energy, but typically there are a few dominant consumers that should be a subject to power optimization.

Wireless connectivity

Wireless communication constitutes a significant portion of the system’s power consumption, so it is important to choose the communication protocol wisely. The basic parameters that go into requirements are data rate, range, whether a complementary receiver/gateway is acceptable, and whether a 3rd party network provider fees are acceptable (as is the case for cellular networks, for example).

An important factor is the wake-up period of the RF communication system. In a transmit-only system, like a temperature sensor, the RF communication will happen at pre-determined intervals which can be quite far apart to conserve energy (e.g. every hour). On the other hand, a smart switch will need to respond to user commands quickly, in real-time. The latency of response is the maximum amount of time it takes for the switch to turn on or off after the user command. Low latency requires the switch to enable the RF communication system more often (e.g. once per second) and causes higher average power usage, albeit delivering a better user experience.

This kind of distinction is well depicted in the LoRaWAN specification, where the three classes of devices differ by when and how often they wake up to transmit or receive messages.

If you want to know more about wireless communication solutions, here is our article that compares different options available on the market.

Light emitters and displays

Light-emitting diodes (LEDs) are mostly included for user interface and user feedback. In that case, they don’t consume a lot of energy. Unless, of course, they are supposed to be enabled during standby, which might drain the battery quite fast if not done properly. It is often a good practice to dim the LEDs by driving them with a PWM signal, to adjust the brightness to an optimal value.

LCD backlight can also consume a significant amount of energy, so it is important to only switch it on when necessary. If an always-on display is needed, consider using e-Ink displays as a low-power alternative. As with everything in engineering, this comes with its tradeoffs.

Always-on sensors

While proximity sensors, image sensors, and microphones might come with low average current, it is vitally important to choose components with adequate energy usage if they are supposed to be running in an always-on mode. Some tips below:

• Proximity sensors with larger ranging distances typically have higher power demands.
• Consider reducing the image sensor update rate, resolution, and region of interest to reduce its power consumption.
• Using monochrome image sensors instead of RGB ones can also lower power consumption significantly.
• Analog microphones have lower power consumption than digital ones but require careful circuit design to ensure good analog signal quality.

Standby leakage current

The standby leakage current can get too high due to circuit design mistakes. Some of the most common are:

• Constant current leakage through smaller value resistors. This often happens if the pull-up/pull-down configuration is not chosen correctly, or the voltage divider resistance is too small.
• Improper power management of system components.
• Using internal RC-based clock sources for RTC instead of the external crystal.
• Inefficient DC/DC converters are enabled during device standby.

To know more on this topic, check our article on optimizing circuits for low power .

Building power consumption model of battery life for IoT devices

To analyze the battery powered IoT device’s life it is useful to have a power consumption model, that describes how much power the device consumes in different conditions and configurations.

The divide and conquer principle is often used to build the mode. It involves breaking down the lifecycle of a device into a set of distinct states and using theoretical or empirical data to assign power consumption to each state. The model can have various input parameters, such as data rate, data resolution, maximum latency, and environmental conditions. Keeping all these parameters as inputs to the model allows us to analyze the system in different configurations and select the most optimal one.

The output of the model could be a battery life duration or the battery capacity/number of cells. The type of output will depend on input parameters. For example, if a model is parametrized by the battery capacity, its output will likely be the battery life given the battery size. On the other hand, it is possible to find the required battery size given the required battery life and other fundamental parameters. Sometimes we need to find optimal values for other model parameters, which is also achievable when a proper model is available.

It is worth noting that, in some cases, battery size (and hence the product size) can be limited, which means optimizing power consumption is crucial to achieving desired battery life, while in other case battery size can be increased to a reasonable degree, without spending significant time and budget on optimization. In both cases, it is valuable to have the correct power consumption model to ensure that the solution cost is as low as possible.

Before modeling power consumption, it is important to lock down the requirements and build a basic operation algorithm. It might also be useful to have multiple power consumption models for different approaches to compare them and select the best one.

Below is the table of typical embedded applications and their projected battery life from two AA alkaline batteries:

Reducing the size of the data to be transmitted

As a rule of thumb, the more data a wireless device needs to transmit, the more energy it will consume, that is why it is important to choose what data to send carefully, and employ various techniques to reduce data size requirements:

• Many of the well-known data compression algorithms can be run even on resource-constrained systems to reduce data size before sending.
• Computer vision algorithms running on the device allow sending metadata instead of the picture (e.g. list of objects), or only sending a section of an image within a particular region of interest.
• Sound classification algorithms only send relevant metadata and events instead of uploading audio data to the cloud.

Most importantly, careful examination of system requirements and data schemas might uncover smarter, application-specific optimizations. For example, relying on previously uploaded data and uploading only the changes (deltas).

Conclusion

Battery life is a key factor in product success and is always a hot topic in embedded product development. It is important to understand how various components contribute to energy draw to ensure the product is feasible and delivers exceptional performance to the user. Using edge computing and advanced AI algorithms can improve the battery life of a product by reducing the amount of costly wireless transmissions, but if used incorrectly, can cause the opposite effect. Experimental data and thorough measurements should be used to justify the use of various optimizations and algorithms.

Power consumption modeling helps to estimate and understand the energy usage of a system. By building a correct model, it is possible to compare different device operation modes and architecture approaches and navigate system tradeoffs.

At Maxlab we design devices powered by batteries and solar panels that run for months or years between charges, from the power model to the board and the firmware. If you are planning one, see our hardware development services; the glossary explains terms such as deep sleep and sleep current.

Common questions