Embedded Low Power Design: How to Extend Battery Life

Why Embedded Low Power Design Decisions are Important?

Your connected device passed bench testing. Battery lasts 18 hours. The product requirement says 7 days. Someone on the team suggests switching to a bigger battery to buy time. The firmware lead says the power consumption hasn't been profiled yet.

This is the moment where six weeks of rework is either avoided or locked in. Embedded low power design decisions made late are expensive to reverse. After hardware is locked, after the wireless stack is integrated, after the software structure is set, the cost of changing direction compounds fast. The decisions made early cost almost nothing.

By the end of this post, you'll know which embedded low power design choices happen at chip selection, which happen in hardware design, and which happen in firmware, and what each one costs if you get it wrong.

Why Most Battery Life Problems Are Architecture Problems, Not Firmware Problems

The instinct when battery life falls short is to fix the firmware. Reduce how often the device wakes up. Cut unnecessary processing. These are real improvements, but they rarely close a large gap on their own.

A device drawing too much current during sleep cannot reach a multi-year battery life target through software alone. The source of that excess current is almost always architectural: a power regulator that does not enter a low-power state, a sensor left powered when the device is idle, a wireless chip that holds an active connection when it should go quiet. These are hardware and architecture decisions. Software cannot fix a hardware power path.

Three categories of embedded low power design decision determine battery life before a line of firmware is written:

• Chip selection: The processor's minimum power consumption during sleep, how quickly it wakes up, and how granularly it can shut down unused components set the floor for what is achievable.

• Hardware power architecture: How power flows to each part of the device, which components share the same power supply, and whether inactive subsystems can be switched off entirely.

• Wireless duty cycle: How often the radio transmits determines how much of the battery the wireless connection consumes. The radio is almost always the largest current draw in an active cycle.

Getting all three right before hardware is finalised is the difference between a 7-day device and an 18-hour device. Most devices that miss their battery life target got one of these three wrong.

Start Embedded Low Power Design at Chip Selection, Not After Hardware Is Locked

The processor selected for a project sets the power floor for the entire design. In embedded low power design, this is the decision with the highest leverage, and it is made before PCB layout begins.

Some processors draw as little as 1–3 microamps when fully asleep with memory retained. Others draw 100 microamps or more in the same state. That difference decides whether a coin-cell device lasts 2 years or 2 weeks, before any firmware decisions are made.

What matters at chip selection:

The most important figure is how much current the processor draws when sleeping. A processor that draws more current asleep than the battery budget allows cannot be fixed with firmware. This number needs to be evaluated and confirmed against the target battery life before any hardware design work begins.

The second consideration is how quickly the processor wakes up. A processor that takes several milliseconds to resume from deep sleep may not be able to respond fast enough to certain sensor events, which forces the device to stay in a lighter, more power-hungry sleep state. Understanding this trade-off before chip selection prevents a late-stage redesign.

The third consideration is how much control the chip gives over powering down individual components independently. A chip that allows the team to shut down the wireless radio, the display, and unused sensors separately, rather than all at once or not at all, gives far more room to optimise in firmware.

Design the Hardware Power Architecture Before the PCB Is Routed

After chip selection, how power is distributed across the PCB determines how close the finished product gets to the processor's theoretical minimum. Three hardware decisions account for most of the gap between what the chip datasheet promises and what the product actually measures in the lab.

The power regulator's idle draw

Every device has a regulator converting battery voltage to the operating voltage the electronics need. That regulator draws current regardless of what the processor is doing. If the regulator draws 100 microamps continuously, the device will never achieve a sleep current below 100 microamps, regardless of how good the firmware is.

For battery-powered products, choosing a regulator with an idle draw under 5 microamps is not a nice-to-have. It is a prerequisite for meaningful battery life. The cost difference between a standard regulator and a low-idle-current regulator is typically under $0.50 per unit. The battery life difference is often measured in weeks.

Switching off subsystems that are not in use

Sensors, displays, and radio modules draw current even when idle. A sensor in standby mode can draw more power over a long sleep interval than the processor itself. The solution is to physically cut power to each subsystem when it is not needed, not just disable it in software.

This is done with a small switching component on each power line, costing $0.05–0.20 per subsystem. When the firmware needs a sensor, it powers the domain on, takes the reading, and powers it off again. This approach can extend battery life by months on devices with multiple sensors.

Passive components left on during sleep

Small resistors used to pull signal lines to a known voltage are a common source of hidden power drain. Each one draws a small but continuous current. On a device with several of these left active during sleep, the combined drain can add tens to hundreds of microamps, enough to cut weeks off the battery life.

Auditing which of these are necessary during sleep and removing or reconfiguring the rest is a low-cost hardware change that happens once, during design review.

Firmware Sleep Strategy: Getting the Device to Actually Sleep Deeply

Once the hardware is correctly built, the firmware determines how close the system actually gets to the hardware's capability. A well-designed chip on a well-designed PCB can still draw 10 times more current than it should if the firmware is not configured to use the deepest available sleep state.

Choosing the right sleep depth

Most processors have multiple sleep levels. Lighter sleep states keep more components active and allow faster wake-up. Deeper sleep states shut down more of the chip and draw far less current, but take longer to resume. For most IoT devices, the deepest sleep state that still allows the device to wake from the required triggers is the right choice.

The common mistake is defaulting to a middle sleep state because it is simpler to configure. That choice can leave a meaningful amount of battery life on the table across every sleep interval.

Preventing unnecessary wake-ups

When a device is supposed to be sleeping, the last thing it should do is wake up unnecessarily. On devices running an operating system to manage tasks and timing, the scheduler itself can generate hundreds of unnecessary wake events per minute if not configured for low power operation.

Configuring the scheduler to suppress these events during idle periods, and instead rely on a dedicated low-power timer for wake-up, keeps the processor in deep sleep for the full intended duration. This single firmware configuration change can reduce active-phase energy consumption by 30–60% on devices with long sleep intervals.

Shutting off components the firmware is not using

Every component the processor has access to (communication interfaces, timers, signal converters) draws a small amount of power when its clock is running, even if no data is moving. Shutting off the clock to each component before sleep, and turning it back on only when needed, eliminates this idle overhead.

On one battery-powered agricultural sensor project, this change alone reduced active-phase power consumption by 35% over the initial firmware pass. The change took less than a day to implement. Battery life improved by three weeks on the same hardware.

Wireless Design: Where Most Battery Life Is Actually Lost

On any connected device, the wireless radio draws more current than almost any other component when active. Getting wireless power consumption right has a larger impact on battery life than any other single firmware decision.

How often the radio is active

A wireless connection that stays active all the time keeps the radio drawing current continuously. Most sensor devices do not need that. A temperature sensor reporting every 5 minutes does not need a connection event every 30 milliseconds, but that is what the default settings on most wireless chips produce.

Configuring the connection to check in less frequently reduces radio-on time dramatically. For a sensor sending data every 5 minutes, tuning this setting alone can reduce radio energy consumption by over 90%. The only trade-off is that the device responds more slowly to incoming commands, which is acceptable for most sensor applications.

Sending data without maintaining a connection

For devices that only send data and never receive commands, maintaining a continuous wireless connection is unnecessary overhead. A simpler approach: the device wakes up, broadcasts its reading, and goes back to sleep. No connection to maintain. No reconnection logic when the connection drops. No waiting for the other side to acknowledge a connection event.

This is more efficient than a persistent connection for any device that purely reports data. The trade-off is that nothing can be sent to the device between its transmissions. For pure sensor devices this is fine. For devices that need remote configuration or control, it is not.

Wi-Fi vs BLE for battery-powered devices

Wi-Fi draws significantly more current than Bluetooth Low Energy during active use. For battery-powered devices, Wi-Fi should only be used when its range or throughput is genuinely required. When Wi-Fi is used, enabling the chip's power-save mode is mandatory. Without it, the radio stays continuously active rather than sleeping between connection checks. Without it, Wi-Fi can drain a battery in hours rather than days.

Measure Power Consumption Before You Optimise It

Power optimisation without measurement is guesswork. Always measure first. A current trace taken on a power analyser shows exactly where the power goes: whether the device is actually reaching deep sleep, which component is drawing unexpected current, and whether the wireless radio is active more often than intended.

Purpose-built power measurement tools for embedded devices cost under $200 and take less than an hour to set up. They produce a graph of current over time that makes every power issue immediately visible.

What a healthy power profile looks like:

• During sleep: current drops to a consistent low floor matching the expected deep sleep level

• During wake: current rises briefly for the sensor reading or data transmission, then drops back

• Radio events: short, predictable bursts at the expected interval, not continuous

Signs of a power problem:

• Sleep current higher than expected: something is still drawing power

• Wake-up events outside the expected schedule: the firmware is waking unnecessarily

• Radio active longer than the transmission should take: retransmissions or a misconfigured connection

Embedded Low Power Design Checklist: Decisions to Make Before Hardware Is Locked

Chip selection:

• Processor sleep current confirmed against battery life target at the expected duty cycle

• Wake-up speed compatible with the fastest response time the product requires

• Chip supports independent power control over each major subsystem

• Low-power wake-up timer available without requiring the main processor clock

Hardware power architecture:

• Power regulator idle current under 5 microamps

• Each sensor and high-draw component has its own switchable power supply

• Always-on pull resistors audited and removed from sleep-phase signal lines

• Wireless radio on a separate, switchable power supply

Firmware sleep strategy:

• Deepest available sleep state configured and confirmed for the application

• Scheduler suppresses unnecessary wake events during idle periods

• Unused component clocks shut off before sleep entry

• Power consumption validated against a measurement tool before firmware milestone

Wireless optimisation:

• Connection check-in interval set to the longest acceptable for the application

• Wi-Fi power save mode enabled if Wi-Fi is used

• Broadcast-only mode evaluated for devices that only send data

• Radio duty cycle measured and validated against the battery budget

Frequently Asked Questions on Low Power Design

What is the most common cause of poor battery life in IoT devices?

The most common cause is a component that remains powered during sleep when it should not be. A sensor in standby mode, a display driver in its default active state, or a power regulator with a high idle draw can each add more current during sleep than the processor itself draws. The fastest way to find the source is to take a current measurement during what should be the sleep phase. If the reading is higher than the processor's datasheet value, something else is still drawing power.

How do you estimate battery life for a connected IoT device?

Battery life is determined by how much current the device draws on average, across both active and sleep phases. A device that is active for 50 milliseconds every 5 minutes, drawing 12 milliamps when active and 4 microamps when sleeping, averages roughly 6 microamps overall. A 500mAh battery at that draw would last several years in ideal conditions. Real battery life is shorter due to temperature effects, battery discharge curves, and self-discharge. The important number is average current, and the only reliable way to get it is measurement, not estimation.

When should a connected device use broadcast-only wireless instead of a persistent connection?

Use broadcast-only when the device only sends data and never needs to receive commands or configuration between transmissions. Environmental sensors, asset trackers, occupancy beacons, and most industrial monitoring devices fall into this category. The power saving comes from eliminating connection maintenance overhead entirely. The limitation is that nothing can be pushed to the device between its broadcasts. If the product roadmap includes remote configuration or firmware updates triggered from the cloud, a persistent connection with infrequent check-ins is the better architecture.

How much does getting low power design wrong add to a project timeline?

Addressing embedded low power design at the right stage, during chip selection and hardware architecture, adds 1 to 2 weeks to the development timeline. Finding it wrong after hardware is locked typically adds 6 to 10 weeks: time for a hardware revision, a new PCB spin, updated firmware, and re-validation. In products with a fixed launch date, that gap is often unrecoverable without cutting scope. The earlier power targets are defined and validated, the lower the cost of any course correction.

What is the difference between a device that is software-disabled and one that is powered off?

A component that is software-disabled is told to stop its normal operation, but it is still receiving power. It still draws current (standby current) which can range from a few microamps to tens of microamps depending on the component. A component that is physically powered off receives no voltage and draws nothing. For battery-powered devices with multiple sensors, the difference between software-disable and physical power-off across all inactive components can add up to hundreds of microamps of unnecessary sleep current. Hardware power switches that allow the firmware to physically cut power to each subsystem are the correct solution for sleep-dominant designs.

What does a power measurement tool actually show?

A power measurement tool displays current draw over time as a graph. During sleep, the line sits at a low, flat level showing the idle power draw. When the device wakes for a sensor reading or wireless transmission, the line spikes to the active current level, then returns to the sleep baseline. This graph makes every power issue visible: a sleep floor that is higher than expected points to a component still drawing power; an unexpected spike points to an unintended wake event; a radio burst that lasts longer than it should points to retransmissions or a misconfigured wireless connection. Without this measurement, power optimisation relies on estimates that are often significantly wrong.

Conclusion

Embedded low power design is an architecture decision, not a firmware fix. The devices that hit 7-day, 90-day, or 2-year battery life targets do so because embedded low power design was treated as an architecture decision from day one, not a patch applied at the end. The right processor was chosen, the hardware was built to switch off what is not needed, and the wireless connection was configured to be active only when necessary.

The checklist in this post covers every decision that needs to happen before hardware is locked. Revisiting these decisions after tape-out is possible, but it costs a respin, a firmware rewrite, and weeks most teams cannot spare.

If you're designing a battery-powered connected device and want to pressure-test your power architecture before hardware is locked, CoreFragment's engineering team has profiled and optimised power consumption across wearables, industrial sensors, and medical devices. Share your requirements and you'll get an honest read on where your current architecture leaves power on the table.