Battery by Design: How Early Architecture Decisions Set IoT Battery Life
Tuesday, October 27, 2026
How early architecture decisions determine runtime, reliability and service cost: a practical framework for teams building connected, battery-powered devices.
Written for product and engineering leaders defining a connected device, preparing to freeze its architecture, or trying to recover a missed runtime target.
01 / Product behavior
Start with the product promise, not the cell
Battery life is often treated as a technical target to validate after the hardware is built, the firmware is running and the industrial design is already committed. For connected products, that is too late.
What "early" means in practice. The concept-definition and system-architecture phase: before the first hardware specification is approved and before enclosure allocation, connectivity strategy, feature scope, and charging or maintenance assumptions are frozen.
The first meaningful question is rarely "Which battery should we use?" More often, it is "What must this product do, under what conditions, and for how long between charges or service events?" That question connects the customer promise to an operating model before cell selection begins.
A wearable, a portable medical device, a pet tracker and a remote industrial sensor may all be battery-powered, but they operate under very different assumptions. Some can be charged every day; others must last months or years. Some can sleep and report only when needed; others must remain reachable, synchronized or responsive much more often.
Those assumptions define the energy model. Sensing frequency, user interaction, local processing, radio activity, mechanical loads, sleep strategy, charging expectations and maintenance model determine the duty cycles and load profiles the battery must support.
At this stage, teams can still trade behavior, connectivity, enclosure size and service expectations against one another. If the mismatch appears after architecture and industrial design are fixed, the same discussion usually becomes a larger battery, a compromised form factor, fewer features, a delayed launch or an unplanned service burden.
Figure 1. Modeling, measurement and validation should update the energy model throughout the product lifecycle, not only after implementation.
Terminology used here. Runtime means time between charges or battery replacements under defined conditions. Battery service life is the interval before the cell or pack must be serviced. Cycle life refers specifically to rechargeable charge-discharge cycles.
Figure 2. Product behavior becomes operating modes, load profiles and, ultimately, runtime, reliability and service outcomes.
From our projects
For Stardust Secured's optical verification device, which works together with a smartphone, the team had to decide early how the add-on hardware would be powered. A second battery would have meant a second charging routine for users in the field. Instead, the team powered the add-on from the phone over the same USB-C link used for data. One charging habit and a simpler accessory were settled before the enclosure design was fixed.
02 / Feature economics
Every feature spends three battery budgets
Product features are usually evaluated by customer value, differentiation and roadmap priority. In battery-powered devices, they also need to be evaluated by their complete system cost.
A new sensor may add warm-up time, sampling, processing, memory activity, calibration and more communication. Frequent updates can improve visibility while extending radio-on time. A richer user experience can be attractive, but not if it forces a charging routine, battery size or maintenance model that no longer fits the market.
Runtime budget | Peak-power margin | Long-term losses |
|---|---|---|
How much battery-terminal energy does the behavior add? | Can the cell and the complete power path deliver the load without a brownout? | What remains active through sleep current, leakage, protection and self-discharge? |
For regulated systems, this analysis belongs at the battery terminals. Converter efficiency, quiescent current, protection circuitry and application cutoff change what the cell actually sees. Charge in mAh should not be added blindly across different voltage domains; battery-terminal energy in Wh or joules makes those conversions explicit.
Figure 3. A useful feature can affect capacity planning, peak-power delivery and long-term parasitic losses.
A battery budget makes trade-offs visible. It helps teams distinguish between what must be always on, what can be event-driven, what can be batched, what can be computed locally, and what should be transmitted only when it creates value.
From our projects
For Snik's anti-theft bike tracker, live location is the feature users care about most, and also one of the most energy-intensive. Instead of tracking continuously, the device stays asleep until motion is detected. It then checks over BLE whether the owner's phone is nearby. Only if it is not does it wake the cellular modem to raise an alert, and frequent GNSS reporting starts only after the owner confirms a problem. The full feature is still there, but the device pays for it only when it creates value.
03 / Communication and positioning
Connectivity turns runtime into a product trade-off
In many connected products, communication is one of the largest and most variable contributors to energy demand. BLE, Wi-Fi, cellular, GNSS and multi-radio architectures influence wake-up behavior, active time, peak current, infrastructure dependencies, retry patterns, and how "live" the product feels.
These technologies cannot be ranked universally by battery cost. The useful comparison is energy per successful transaction or position fix, together with peak current, latency, reachability and the assumptions behind the result. Payload size, RF conditions, protocol state, network configuration and power-management strategy can reverse a simplistic ranking.
Figure 4. Compare communication and positioning options under stated product, protocol, infrastructure and RF assumptions.
Real-time cloud access, continuous reporting and constant reachability may sound attractive, but each has consequences for runtime, operating cost and field reliability. Often, the best strategy is not maximum connectivity. It is the right transaction at the right moment.
A store-and-forward workflow, gateway-assisted architecture, selective reporting policy or event-driven synchronization model can preserve product value while making the runtime target much more realistic. For a comparison of long-range options, see our overview of IoT connectivity: LoRaWAN, 5G and Nordic NR+.
From our projects
On the same cellular bike tracker, every GNSS fix is receiver-on time the battery pays for. In bench tests without assistance data, the original board needed 138–157 s for a cold fix. After a board redesign, cold fixes took 28–39 s, and with A-GPS they stayed in the 24–53 s range across board versions and with the enclosure fitted. Warm fixes were mostly under 10 s. Every second the GNSS receiver is not searching is energy the battery keeps.
04 / Load profiles
Average current is necessary, but not sufficient
Average battery-terminal current over a representative duty cycle is valid and necessary for charge budgeting. It is not sufficient to establish runtime, peak-power capability or brownout margin.
The battery and power tree experience the full load profile: peaks, pulse duration, idle periods, overlapping tasks, retries, reconnects, radio attach cycles and recovery time. Source impedance, regulator dropout, application cutoff, temperature, state of charge and aging determine whether those events can be delivered reliably.
Average current helps size capacity. Load profiles reveal whether the system can deliver it reliably.
Figure 5. Conceptual profiles with approximately equal integrated charge can produce different voltage margins under load. Not to scale.
This is also why laboratory estimates and field behavior diverge. Real RF coverage, backend-driven wake-ups, OTA updates, retry storms, debug interfaces, temperature, battery aging and user behavior can reshape both the total energy and its delivery profile.
Validation should include the complete product without debug power paths, at low state of charge and end-of-life conditions, across expected temperature and RF extremes. The acceptance criteria should include runtime, minimum battery voltage, reset behavior and thermal limits, rather than a single average current value.
From our projects
On a wrist-worn child-safety wearable that uses UWB ranging, power profiling showed that the measurement itself was not the main runtime problem. Ranging at 5 Hz added only about 4 mA over the radio's idle state, even with peaks near 250 mA. Keeping the receiver continuously ready for the next request drew 89 mA in total, enough to empty a 350 mAh cell in about four hours. The main lever became when the device listens, not how often it measures. A first-order model with duty-cycled listening comes close to a full day on the same cell (about 22 hours), and closing the rest of the gap became a firmware-architecture task.
05 / Product envelope
Form factor, chemistry and safety must be designed together
When runtime and peak-power requirements are held constant, reducing enclosure volume can limit stored energy and compress electrical, mechanical and thermal margins. Compactness alone does not determine risk, but it reduces the room available to resolve conflicting requirements.
Figure 6. Compact products make trade-offs more tightly coupled when runtime, peak power and product constraints remain fixed.
Chemistry adds another layer. Cell families trade energy density, cycle life, safety behavior, charging requirements, cost, temperature robustness, pulse capability, availability and compliance in different ways. The cell with the highest headline capacity is not necessarily the strategy that best supports the product lifecycle.
Figure 7. Chemistry, construction and format should be evaluated using manufacturer data at the expected load, temperature, cutoff, storage and aging conditions.
Safety and thermal design are system requirements for every battery-powered product. The required controls and validation depth depend on chemistry, stored energy, charge and discharge rates, enclosure, foreseeable misuse and application risk. Cell choice, charging, mechanical protection, thermal paths, monitoring thresholds and protective electronics must work as layers.
Cell-level approvals do not by themselves establish pack or end-product compliance. Transport testing such as UN 38.3 and safety standards such as IEC 62133-2 or IEC 60086-4 address different parts of the compliance picture; applicable product and market requirements still need their own review.
From our projects
For ITR's permanently installed wireless sensor network for predictive maintenance, the endpoints use a Li-SOCl₂ bobbin cell for its high energy density and low self-discharge. The chemistry fits a long service interval, but it changes other parts of the system. A standard fuel gauge gave unreliable percentage estimates on this chemistry, so state of charge needed a dedicated measurement method with a brief, controlled resistive load. The firmware runs bare-metal on a low-power MCU to keep active time short. Choosing the cell meant also choosing how to measure it and how to load it.
06 / Customer experience and operations
Battery life is part of the product promise
Battery life is not just a number in a specification. It is part of the experience customers buy into. A wearable may succeed with daily charging if the routine feels natural. A remote sensor that requires frequent maintenance may fail commercially even when the electronics work as designed.
A connected industrial device that promises continuous visibility but drains too quickly can damage trust beyond the device itself. A small change in replacement frequency can also become a major operating expense when multiplied across an installed fleet.
Figure 8. Runtime shapes customer experience, service operations, support burden and product positioning.
That makes runtime a marketing, operational and service decision. It influences perceived reliability, support burden, replacement cycles, SLA credibility, warranty exposure, customer satisfaction, and the gap between what the product promises and what the organization can sustain.
Preserve future options. Replaceable versus rechargeable cells, sealed versus serviceable enclosures, traceability, accessible diagnostic data and end-of-life handling can preserve or close options for maintenance, redeployment, compliance and circularity. These belong in the service model, even when circularity is not the first-release priority.
From our projects
For Beadedstream's temperature data loggers, deployed at remote sites in extreme climates and reporting over satellite, every service visit is expensive. A core part of the product's value is needing less field maintenance than competing loggers. Our work focused on sleep current: low-power handling of idle digital interfaces, and an intermediate low-power mode so the device could blink a status LED without fully waking. Health and diagnostic messages were added so problems could be seen remotely. One lesson stayed with our team: a power fix without a regression test came back on the next product family.
07 / Alignment and execution
Align the product promise with the energy model
A defensible battery strategy ties each runtime claim to an operating model, a measured load profile, peak-power margin, environmental assumptions and a service plan. The checklist below turns those inputs into an architecture-review gate and a validation baseline.
Figure 9. A system-level checklist connects product success criteria with realistic conditions, measurement, safety and service operations.
From alignment to execution
These decisions cross product, electronics, firmware, RF, mechanical design, validation and operations. When ownership is fragmented, gaps can remain between the runtime promise and what the complete device can demonstrate.
A system-level engineering partner can close those gaps by making assumptions explicit, connecting decisions across disciplines, and turning them into measurements and acceptance criteria.
How iomico helps
iomico connects product decisions with embedded hardware, firmware, connectivity and field validation. The work can begin during concept and system architecture, or when a prototype is already missing its runtime target.
Define and model | Measure and diagnose | Design and validate |
|---|---|---|
Clarify runtime targets, use cases, duty cycles, service assumptions and acceptance conditions. | Profile battery-terminal behavior, peak events, parasitic losses, field exceptions and brownout risk. | Prioritize hardware, firmware, connectivity, power-tree and validation changes that protect the product promise. |
Depending on scope, the resulting engineering package can include:
Energy budget and operating model
Load-profile characterization
Battery and power-tree risk assessment
Hardware and firmware recommendations
Connectivity and retry strategy
Runtime validation plan
FAQ
When should battery life be decided in a connected product?
During concept definition and system architecture: before the hardware specification is approved and before enclosure size, connectivity strategy, feature scope and charging or maintenance assumptions are frozen. After that point, a missed runtime target usually means a larger battery, a compromised form factor, fewer features, a delayed launch or an unplanned service burden.
How do you estimate battery life for an IoT device?
Start from the product's operating model (what it senses, how often it communicates, how long it sleeps), turn it into duty cycles and load profiles, and budget energy at the battery terminals in Wh or joules rather than adding mAh across voltage domains. Then check peak-power margin and long-term losses such as sleep current and self-discharge, and validate on the complete device at low state of charge, end of life, and temperature and RF extremes.
Is average current enough to predict runtime?
No. Average current is necessary for sizing capacity, but it does not show whether the cell and power path can deliver peaks without a brownout. Two load profiles with roughly the same total charge can produce very different voltage margins, especially at low state of charge, low temperature or end of life.
Which radio uses the least battery: BLE, Wi-Fi, cellular or GNSS?
There is no universal ranking. The useful comparison is energy per successful transaction or position fix, together with peak current, latency and reachability, under stated assumptions. Payload size, RF conditions, protocol state, network configuration and power-management strategy can reverse a simplistic ranking.
Designing a battery-powered product or missing your runtime target?
Turn runtime assumptions into a measurable architecture and validation plan. Talk to iomico about product behavior, power architecture, connectivity and field conditions.
