Low-power design · Updated October 2026

How to estimate battery life for IoT devices

A four-step method for working out how long a battery-powered sensor, tracker or camera will run, with worked examples for Wi-Fi, always-on AI and a camera that wakes on motion.

Battery cells for a battery-powered IoT device

Quick answers

  1. How do I estimate IoT battery life? Average the current over one sleep-and-wake cycle, then divide the usable capacity (70–80% of the label) by that average. The four steps
  2. Can a Wi-Fi device run for years on batteries? Yes, if it reports rarely: a sensor that sends one reading an hour averages 0.066 mA and lasts about three years on two AA cells. Wi-Fi example
  3. How long does a camera that wakes on motion last? About 500 days on a 3,000 mAh LiPo at 20 events a day, and half that at 40 events. Camera example
  4. What uses up the battery first? The radio, then anything that has to stay on; once those are under control, leakage in sleep sets the limit. What drains it
  • Wi-Fi sensor, 2 × AA≈3 yearsuploading once an hour
  • Motion camera, 3,000 mAh≈500 daysat 20 events a day on a LiPo cell
  • Capacity to subtract20–30%of the label rating, for the regulator, cut-off voltage, cold and self-discharge
  • Tracker standing still≈1000×less system power when an accelerometer stands in for the GPS

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. Time each state

Note how long each state lasts per cycle, and how often the cycle repeats.

3. Average the current

Iavg = (I1·t1 + I2·t2 + …) / cycle time.

4. Divide usable capacity by Iavg

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.

How long do battery-powered IoT devices last?

Three worked examples with the four steps above. The same method gives months for one device and days for another; what changes is how long each one stays awake.

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.

  • Wi-Fi
  • 2 × AA
  • ≈ 7 months

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.

  • Edge AI
  • 2 mA always on
  • ≈ 5 weeks

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. Choosing a board for a battery camera? See ESP32-CAM vs Tokay Lite.

  • PIR wake
  • 3,000 mAh LiPo
  • ≈ 500 days

Where does the charge go?

Upload once an hour instead of every 10 minutes and the Wi-Fi sensor's 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. Our low-power wireless MCU comparison lists the sleep and radio currents of current parts.

Where the battery charge goes in four worked examples: share spent awake and share spent asleepWi-Fi sensor, every 10 min: 97% awake, 3% asleep, battery life about 7 months; Wi-Fi sensor, every hour: 85% awake, 15% asleep, battery life about 3 years; Motion camera, 20 events a day: 90% awake, 10% asleep, battery life about 500 days; Always-on keyword spotting: 100% awake, 0% asleep, battery life about 5 weeks.SHARE OF THE CHARGE ·AWAKE·ASLEEPBATTERY LIFEWi-Fi sensor, every 10 min≈ 7 months97% awake3% asleep2 s at 100 mA awake, 10 µA asleepWi-Fi sensor, every hour≈ 3 years85% awake15% asleepsame sensor, one upload an hourMotion camera, 20 events a day≈ 500 days90% awake10% asleep5 s at 150 mA per event, 20 µA asleepAlways-on keyword spotting≈ 5 weeks100% awake2 mA, never sleeps
Share of each worked example's charge spent awake and asleep, from the figures above.

How does a battery-powered device spend its time?

An IoT battery product sits in its lowest-power state most of the time to maximize battery life. Communication interfaces, sensors and data processing are off. This state is often called standby or power-down.

A purely wakeup-based system stays in this state with a minimum of components active. The simplest example is a button-based wake-up: the device's power is switched on by a button press, so only a small part of the circuit draws power to watch the button. A real-time clock can be kept running to allow time-based wakeups, either periodically or at a set time.

Often we need to monitor the environment continuously and react to sudden changes. This is the always-on case, which usually means a bigger part of the device is awake all the time. An always-on temperature sensor can wake the system when the temperature reaches a critical level and send an alert to the cloud. A smart speaker keeps its microphone and audio processor powered to detect and classify wake words.

In always-on designs, pay special attention to the power consumption of the always-on components, because they are likely to set the battery life of the whole product.

Multi-level sensing

Sometimes the parts that should run always-on draw too much for the battery-life target. Then a multi-level approach helps: a cheap sensor watches, and the expensive one wakes only when needed.

A location tracker can use a low-power accelerometer instead of keeping the GPS receiver on, so system power is about 1000× lower while the tracker is not moving. An AI camera does not need to look for objects in an empty scene when a proximity sensor or light detector can switch it on.

  • Accelerometer before GPS
  • PIR before camera
  • Voice activity before wake word

What drains an IoT device battery?

An embedded device has many parts that draw current, but a few dominant consumers usually decide the battery life. Optimize those first.

Wireless connectivity

The radio is a large share of the system's consumption, so choose the protocol with care. The requirements to settle first: data rate, range, whether a separate receiver or gateway is acceptable, and whether third-party network fees are acceptable, as they are for cellular.

The wake-up period of the radio matters as much. A transmit-only temperature sensor can send at intervals far apart, such as every hour. A smart switch must answer user commands quickly, so it turns its radio on more often (for example once per second) and uses more power for the shorter latency. The three LoRaWAN device classes differ in exactly this: when and how often they wake to transmit or receive. Our article on low-power wireless MCUs compares the options on the market.

  • Data rate
  • Range
  • Gateway or not
  • Latency

Light emitters and displays

LEDs are mostly there for user feedback, and then they draw little. An LED left on during standby is different: it can drain the battery fast. Driving LEDs with PWM lets you dim them to the lowest brightness that still works.

An LCD backlight can also draw a lot, so switch it on only when needed. If the display must stay on, an e-ink display is the low-power alternative, with its own tradeoffs.

  • PWM dimming
  • Backlight off
  • E-ink

Always-on sensors

Proximity sensors, image sensors and microphones may have a low average current, but if they run always-on, their consumption needs checking part by part:

  • Proximity sensors with longer ranging distances usually need more power.
  • Lower the image sensor's update rate, resolution and region of interest to cut its consumption.
  • A monochrome image sensor instead of an RGB one can draw much less.
  • Analog microphones draw less than digital ones but need careful circuit design for a clean signal.

Standby leakage current

Standby leakage gets too high through circuit design mistakes. The most common:

  • Constant current through small resistors, from a wrong pull-up or pull-down choice or a voltage divider with too little resistance.
  • Poor power management of system components.
  • An internal RC oscillator for the real-time clock instead of an external crystal.
  • Inefficient DC-DC converters left enabled during standby.

More in our article on low-power circuit design.

How do you build a power consumption model?

A power consumption model describes how much power the device draws in different conditions and configurations. It is how you analyze a battery-powered device's life before the hardware exists.

Break the lifecycle into states

Divide and conquer: split the device's lifecycle into distinct states and assign power to each from theory or measurement. Keep data rate, data resolution, maximum latency and environmental conditions as model inputs, so you can compare configurations and pick the best one.

Choose what the model answers

Parametrize it by battery capacity and it gives the battery life. Turn it around and it gives the battery size, or number of cells, needed for a required life. A good model also finds the best values for other parameters.

Lock the requirements first

Settle the requirements and a basic operating algorithm before modelling. Where the battery size, and so the product size, is fixed, power optimization decides whether the target is met. Where the battery can grow, a bigger cell may cost less than weeks of optimization. Build several models for different approaches and compare them.

Typical embedded applications and their projected battery life from two AA alkaline cells

Estimated battery life of seven typical embedded applications on two AA alkaline cells, on a logarithmic time axisBLE beacon, temperature every second: 1 year; Wi-Fi, 200 kB every 10 minutes, no kept connection: 2 months; NB-IoT, listening for MQTT commands (1–2 s latency): 3 weeks; Microphone recording to internal memory: 17 days; Infrared time-of-flight proximity at 10 Hz: 10 days; GPS tracker at 1 Hz, no data connection: 40 hours; 2 MP camera streaming 15 fps over Wi-Fi: 5 hours.BATTERY LIFE ON TWO AA ALKALINE CELLS (LOG SCALE)1 hour1 day1 week1 month1 yearBLE beacon, temperature every second1 yearWi-Fi, 200 kB every 10 minutes, no kept connection2 monthsNB-IoT, listening for MQTT commands (1–2 s latency)3 weeksMicrophone recording to internal memory17 daysInfrared time-of-flight proximity at 10 Hz10 daysGPS tracker at 1 Hz, no data connection40 hours2 MP camera streaming 15 fps over Wi-Fi5 hours
From the table below. The time axis is logarithmic: each gridline is a day, a week, a month or a year.
ApplicationBattery life estimate
BLE beacon transmitting temperature data every second1 year
Sending 200 kB of data via Wi-Fi every 10 minutes, not maintaining connection2 months
NB-IoT device listening for MQTT commands with 1–2 seconds latency3 weeks
Microphone recording into internal memory, no upload17 days
Infrared time-of-flight proximity running detection at 10 Hz10 days
GPS tracker with 1 Hz update period, no data connection40 hours
2 MP camera streaming video at 15 fps via Wi-Fi5 hours

How do you cut the energy spent sending data?

The more data a wireless device transmits, the more energy it uses, so choose what to send with care and make it smaller. Doing the heavy processing on the device, including machine-learning models at the edge, also cuts the cost of uploading raw data and processing it in the cloud.

Compress before sending

Many well-known compression algorithms run even on resource-constrained systems and shrink the payload before it goes on air.

Send results, not pictures

Computer vision on the device can send metadata, such as a list of objects, instead of the picture, or only the part of the image inside a region of interest.

Send events, not audio

Sound classification on the device sends the relevant events and metadata instead of uploading audio to the cloud.

A careful look at the system requirements and data schemas often turns up application-specific savings, for example uploading only the changes (deltas) against data already sent.

Measure before you optimize

Edge computing and on-device AI can extend battery life by cutting costly wireless transmissions, but used in the wrong place they shorten it. Understand how each component adds to the energy draw, model it, and back every optimization with measurements. A correct model lets you compare operating modes and architectures before you commit to one.

Where this applies at Maxlab

Tokay Lite, our open-source ESP32-S3 camera board, is built for the motion-camera case above. A PIR sensor or a timer wakes it, it takes the picture, runs face or object detection on the board, sends the result over HTTP or MQTT and goes back to sleep. An external real-time clock switches the regulator off between events, so standby draw is in microamps. The schematic and SDK are on GitHub.

The solar roof camera on our work page is the same platform in a client product: 9,500 units shipped, about six months per charge. If you are planning a device that has to run for months or years between charges, our hardware and firmware services cover the power model, the board and the firmware. The glossary explains terms such as deep sleep and sleep current.

Wake sources
PIR motion sensor or real-time clock timer
Battery
1-cell LiPo, charger on the board
Shipped on this platform
9,500 solar roof cameras
On one charge
About six months in the roof camera
Tokay Lite camera board in its enclosure

Planning a device that runs on a battery?

Send us the battery you have in mind, how often the device wakes and which radio it uses. We reply within 24 hours.

Or email [email protected] or book a 30-minute call.

Common questions

How do I estimate the battery life of an IoT device?

List the device's states (sleep, measure, process, transmit), note the current and duration of each per cycle, and average them: I_avg = (I1·t1 + I2·t2 + …) / cycle time. Battery life is the usable capacity, about 70–80% of the label, divided by I_avg. A sensor averaging 0.34 mA on two AA cells (about 1,750 mAh usable) runs roughly seven months.

How do I estimate battery life for always-on inference such as keyword spotting or simple vision?

Use the inference current as the average, because the device never sleeps. At 2 mA, two AA cells last about five weeks and a CR2032 coin cell about four days. To reach months, run the model on a part that draws under about 100 µA, or let a low-power trigger (voice-activity detector, PIR, accelerometer) wake the inference core only when needed.

Which wireless technology gives the longest battery life for periodic data uploads?

For small, periodic readings, Bluetooth Low Energy, Zigbee and Thread use the least energy per message: a few milliseconds of radio time at single-digit milliamps. Wi-Fi typically needs one to three seconds at around 100 mA to join and send, unless the device keeps its connection in a power-save mode. LTE-M and NB-IoT cost more per message but need no local gateway; their power-saving modes (PSM, eDRX) make hourly or daily uploads practical on batteries.

How long does a coin cell last in a smart-home sensor?

Zigbee and BLE door, temperature and motion sensors on a CR2032 are typically rated for one to two years. The real figure depends on how often the sensor reports and on its sleep current; a coin cell cannot supply the current that Wi-Fi needs.

How do I compare the battery life of industrial wireless sensors?

Compare them at the same reporting interval and temperature, and ask for the average current, not just the sleep current. Check the battery chemistry and its derating in cold, the radio's time on air per message, and whether the quoted life assumes a gateway close by. A short measurement with a power analyser over a few full cycles settles most disagreements.

What draws the most power in a battery-powered device?

Usually the radio, then anything that must stay on: always-on sensors, LEDs or a display backlight. In sleep, leakage through pull-up resistors and voltage dividers, an idle DC-DC converter or an RC oscillator instead of a crystal for the real-time clock can dominate.