22 Device Power Management
connected device power management, IoT power review, battery readiness, duty cycle review, power state record, IoT battery service interval
22.1 Start Simple
A battery claim is a user promise, not just an electrical estimate. Start with the work the device must do, the power states that support it, the feedback users need when energy is limited, and the evidence that proves the product will last in its real duty cycle.
22.2 In 60 Seconds
Power management is the review of how a connected device spends energy over time. It covers active work, sleep behavior, sensors, radios, displays, actuators, regulators, batteries, charging, service intervals, and user-visible low-power behavior.
The useful question is not “what is the battery size?” The useful question is whether the measured power states, duty cycle, deployment environment, update path, and maintenance plan support the claimed service interval.
Phoebe’s Why
The annotated power-profile figure later in this chapter already shows this device is not a simple sleep/active switch – it is four states with four different currents: about 10 microamps asleep, 5 mA sensing, 15 mA processing, and 120 mA transmitting. A two-term duty-cycle formula throws away exactly the information that figure is trying to preserve. The honest average current is a time-weighted sum across every state the firmware actually visits, and because it is time-weighted, the state that lasts longest can dominate even when its current is the smallest – which is exactly why this chapter insists on measuring wake frequency, not just peak transmit current, before signing off a service-interval claim.
The Derivation
Time-weighted average current across \(k\) states of current \(I_i\) and duration \(t_i\) within a repeating cycle \(T\):
\[I_{avg}=\frac{\sum_i I_i\,t_i}{T}\]
Usable charge derates for self-discharge compounding over the deployment life \(y\) years at rate \(r\) per year – a separate loss from the sleep/active budget above:
\[Q_{usable}(y)=Q_{nominal}\,(1-r)^{y}\]
Worked Numbers: This Chapter’s Own Four-State Profile at Two Report Intervals
- Using this chapter’s own figure (\(I_{sleep}=10\ \mu A\), \(I_{sense}=5\) mA for 50 ms, \(I_{compute}=15\) mA for 20 ms, \(I_{tx}=120\) mA for 100 ms, catalog-typical durations) on a \(300\) s report interval: \(I_{avg}=\left[0.010\times299.83+5\times0.05+15\times0.02+120\times0.10\right]/300=51.8\ \mu\text{A}\).
- Catalog-typical Li-SOCl2 primary cell (\(Q_{nominal}=2400\) mAh) at \(1.00\%\)/year self-discharge: after 2 years, \(Q_{usable}=2400\times0.99^2=2352\) mAh, giving a 2-year current budget of \(2352\text{ mAh}/17{,}520\text{ h}=134\ \mu\text{A}\).
- At the 300 s interval, \(51.8\ \mu\text{A}\) leaves a \(134/51.8=2.59\times\) margin under that budget – the two-year claim holds with room to spare.
- Tightening the report interval to 60 s (five times more frequent, no other change) raises \(I_{avg}\) to \(219\ \mu\text{A}\) – over the \(134\ \mu\text{A}\) budget, giving only \(2352/0.219=10{,}700\) h \(\approx1.23\) years of life. Nothing about the sleep current, the radio, or the cell changed; only the wake frequency did – exactly the “rerun the review when wake frequency … changes” rule this chapter already states, now with the arithmetic that makes it fail.
- This chapter’s own protocol list (BLE, Wi-Fi, Thread, Zigbee, LoRaWAN, cellular) mostly trades band and modulation for the duration and current of that transmit term, not the formula itself: a sub-GHz LoRaWAN burst can hold a lower \(I_{tx}\) than 2.4 GHz BLE for the same range, or a longer \(t_{tx}\) for the same \(I_{tx}\) from its slower spreading, so a band or protocol change should be read as a new \((I_{tx}, t_{tx})\) pair in the same \(I_{avg}\) sum above, not a separate calculation.
22.3 Learning Objectives
By the end of this chapter, you will be able to:
- review a connected-device power budget from measured states rather than assumptions
- explain how duty cycle, sleep current, radio use, sensing, actuation, and displays affect service interval
- identify checks needed for battery, mains, charging, harvesting, and backup power decisions
- connect power behavior to user experience, maintenance, OTA updates, and lifecycle risk
- write a bounded power record with accepted limits, owners, and change conditions
22.4 Minimum Viable Understanding
A power claim is reviewable only when it names the power source, measured device states, timing assumptions, service target, deployment conditions, and what happens when the energy budget is not met.
Avoid treating battery life as a fixed property of a part. Battery life depends on the whole system: sleep leakage, wake frequency, radio retries, sensor warm-up, actuation loads, displays, temperature, aging, self-discharge, installation context, and maintenance behavior.
22.5 Prerequisites
This chapter builds on:
- Connected Device Fundamentals, which defines the device role and boundary.
- Device Form Factors, which reviews battery volume, access, enclosure, and service constraints.
- Device Lifecycle Management, which reviews operation, updates, maintenance, and retirement.
- Energy Aware Considerations, which expands system-level energy choices.
22.6 Overview: Power Is a Service Promise
Connected-device power design is not just choosing a larger cell. It is the service promise that says how long the device can sense, compute, communicate, update, warn, and recover before someone must charge, replace, inspect, or retire it.
For a battery sensor, the promise depends on sleep current, wake interval, sensor warm-up, radio join or transmit time, acknowledgement policy, retry behavior, battery chemistry, temperature derating, regulator quiescent current, and the physical service path. For an interface or actuator, it also depends on displays, LEDs, haptics, motors, relays, locks, valves, and whether low-power mode changes the user-visible behavior.
The same nominal battery capacity can support very different products. A CR2032 beacon that advertises every few seconds may be limited by pulse current and radio schedule. A Li-SOCl2 field sensor may be limited by cold-temperature voltage sag and passivation after storage. A Li-ion handheld reader may be limited by display brightness, user charging habits, and charger access. A mains-powered gateway may still need backup power long enough to flush buffers, preserve endpoint state, and report the outage cleanly.
Review the claim as a service interval, not a datasheet lookup. The record should show the energy source, measured states, expected event rate, installed radio behavior, derating assumption, low-power threshold, warning path, service owner, and change condition. If the device saves energy by reducing sampling, turning off live status, delaying uploads, or disabling actuation, that tradeoff belongs in the product record because it changes what users and support staff experience.
- Measure states: deep sleep, idle, sensing, compute, transmit, receive, display, actuation, charging, and update.
- Measure timing: wake source, active duration, retry window, heartbeat interval, emergency event, and service interval.
- Design degradation: warn early, preserve core function, defer noncritical work, and explain low-power behavior to support staff.
22.7 Budget from Workload
Start with a current trace from the real firmware. Nordic Power Profiler Kit, Otii Arc, Joulescope, Monsoon, a source-measure unit, or a shunt plus oscilloscope can show whether the device actually reaches sleep, how long the radio stays awake, and whether pull-ups, debug headers, sensors, or regulators leak current.
Turn that trace into a workload budget. Record the current and duration for each state, multiply by how often the state occurs, then compare the daily or monthly total with usable battery energy after regulator efficiency, temperature, storage age, self-discharge, and required reserve are applied. Keep peak-current checks separate from average-current checks: a coin cell may have enough nominal capacity but still brown out during a BLE transmit burst, a cellular attach, a relay pulse, or a flash erase.
- Bound the power source. Name the chemistry or supply, such as CR2032, AA lithium primary, Li-SOCl2, Li-ion/LiPo, supercapacitor, USB, PoE, vehicle 12 V, solar plus charger, or mains with backup.
- Model the communications path. Compare BLE advertising/connection intervals, Wi-Fi association and DTIM behavior, Thread sleepy end devices, Zigbee polling, LoRaWAN Class A receive windows, LTE-M or NB-IoT attach/PSM/eDRX behavior, and gateway retry policy against the actual payload schedule.
- Gate risky operations. Require enough energy and storage for firmware download, signature verification, flash write, reboot, boot confirmation, rollback, and post-update health before OTA starts.
Run at least one review in the installed context. Place the gateway where it will actually sit, close the enclosure, use the intended antenna, sample the expected sensor mode, measure low-battery behavior, and force weak-signal or retry cases. For solar or harvested designs, include the worst charging window, load-shedding rule, storage reserve, and what support sees after several low-energy days. For rechargeable devices, include charging time, connector wear, cable availability, heat, and whether the user can recover without losing pairing or configuration.
The decision should include derating. Temperature, battery age, pulse-current limits, enclosure heat, solar shading, self-discharge, and storage time can change the usable energy before the device ever reaches the customer. ## Average Current Hides Failures {.depth-l2}
Average current is useful, but it can hide the state that breaks the product. A device with excellent sleep current can still fail if weak signal causes repeated joins, if TLS handshakes keep the modem awake, if a sensor heater stays on, if a buck regulator is inefficient at microamp loads, or if a brownout happens during flash writes.
Power design needs state-aware firmware. Use RTC wakeups, GPIO interrupts, sensor power rails, regulator enable pins, modem PSM/eDRX, BLE connection parameters, LoRaWAN data-rate adaptation, local buffering, and low-battery thresholds deliberately. Store enough counters for support to distinguish a power problem from network loss, firmware crash, sensor fault, or normal sleep.
The firmware state machine should make energy decisions explicit. It should know when it is manufactured, provisioned, commissioned, normal, degraded, low-battery, charging, updating, rollback, factory-reset, or retired. Each state needs rules for sampling, radio use, actuation, local storage, user indication, command acceptance, and update deferral. A low-battery state that only changes an internal flag is not enough if the app still shows fresh data or lets a user request an operation the device can no longer complete.
Hardware details can also invalidate a clean average-current spreadsheet. Pull-up values, sensor power rails, regulator quiescent current, leakage through protection parts, flash erase current, display refresh, modem attach bursts, brownout threshold, fuel-gauge calibration, and battery internal resistance all affect the field result. Record counters such as brownouts, failed joins, retry minutes, update deferrals, low-power entries, charge cycles, and minimum observed voltage so support can diagnose the actual energy path rather than guessing from “offline” status.
- Energy state: track battery voltage, estimated state of charge, temperature, charge cycle, brownout count, and low-power entry reason.
- Radio state: track join attempts, RSSI/SNR or RSRP/RSRQ, retries, receive-window time, attach time, and bytes sent.
- Update state: track package size, flash writes, verification result, active slot, confirmed boot, rollback reason, and deferred update count.
22.8 Power Review Path
Use Figure 22.2 to keep the review grounded:
- Power source: battery, mains, charging, harvesting, vehicle power, backup, or mixed source.
- Measured states: sleep, idle, sensing, compute, transmit, receive, display, actuation, charge, and update.
- Duty cycle: how often each state occurs, how long it lasts, and what causes it.
- Connectivity: connection setup, retry behavior, listening windows, acknowledgements, buffering, and gateway dependence.
- Environment: temperature, enclosure heat, sunlight, moisture, storage, aging, and service access.
- Service interval: charge, replace, inspect, clean, or recover before user trust is lost.
- User behavior: notifications, indicators, live view, manual commands, and degraded operation at low power.
- Update gate: enough energy and storage to download, verify, write, reboot, and roll back.
- Record and change condition: accepted tradeoff, owner, known limit, open issue, and change condition.
22.9 Power Source And Boundary
Start with the power boundary. A device may look battery powered but depend on a gateway, phone, charger, solar panel, vehicle bus, or maintenance visit.
Review:
- the primary power source and any backup source
- what is inside the measured device boundary
- whether cables, chargers, gateways, batteries, or replaceable packs are part of the product
- whether a user, installer, technician, or operator can reach the power source
- what state survives battery removal, brownout, reset, or charger loss
- what must be shown to users or operators before the device becomes unreliable
If the power boundary is unclear, battery-life claims and service claims will also be unclear.
Use Figure 22.3 to make the source boundary explicit before estimating service life. The power record should state why the selected source fits the deployment duration, access model, and environmental exposure.
22.10 Measured Power States
A power budget should be based on measured states, not only datasheet values.
Common states to measure:
- Deep sleep: timer, interrupt, retention memory, leak paths, and powered peripherals.
- Idle connected: radio association, keepalive, receive windows, status lights, and background tasks.
- Sensing: sensor warm-up, sampling, filtering, calibration, and stabilization time.
- Compute: processing, local decisions, encryption, compression, and inference.
- Transmit and receive: connection setup, payload send, acknowledgement, retry, and disconnect.
- Actuation: motors, relays, locks, valves, haptics, lights, and safety interlocks.
- Display and feedback: screen, LEDs, audio, vibration, and user-facing status.
- Update: download, verify, write, reboot, rollback, and post-update health check.
Record the measurement setup. The same board can draw different current depending on firmware build, pull-ups, regulator choice, sensor mode, antenna placement, debug headers, and sleep configuration.
Use Figure 22.4 when reviewing measured-state evidence. The power record should say which rails were instrumented, which firmware state produced each trace, and which fixes changed the budget.
22.11 Duty Cycle Review
Duty cycle is the schedule of how long the device spends in each state.
Review:
- wake source: timer, event, user input, interrupt, gateway command, or schedule
- active work: measure, compute, store, transmit, listen, display, or actuate
- sleep or idle duration between active periods
- retry rules after failure
- heartbeat or last-seen reporting
- behavior when readings are unchanged
- behavior when readings are urgent
The average current is a time-weighted result. A short high-power state may matter less than a long idle state, while a small sleep leak may dominate a device that sleeps almost all the time.
Use a simple evidence statement:
- measured current for each state
- duration of each state
- expected frequency
- deployment derating
- service interval target
- change condition
Use Figure 22.5 to keep average-current claims tied to timing evidence. A power budget should make the active interval, sleep interval, retry window, and exception cases visible instead of hiding them behind one battery-life number.
22.12 Connectivity Energy
Radio power cannot be reviewed from protocol labels alone.
Review:
- whether the device must scan, join, associate, authenticate, or reconnect
- how long it listens before or after sending
- how retries and acknowledgements work
- whether the gateway buffers or wakes the endpoint
- payload size and send frequency
- link behavior after installation, not only on the bench
- fallback behavior when the link is weak
Do not accept broad claims such as “low-power protocol” or “Wi-Fi is too power hungry” without the actual workload, installed signal path, and measured state evidence. The same radio can be reasonable or unreasonable depending on connection schedule, payload, retry policy, and power source.
22.13 Battery, Charging, And Service
Battery and charging decisions are also UX and maintenance decisions.
Review:
- capacity, usable energy, voltage range, cutoff behavior, and aging assumption
- temperature effect in the intended environment
- self-discharge or standby drain over the expected storage and deployment period
- charger availability, charging time, connector access, and indicator behavior
- replacement path, tool requirements, sealing, labels, and safe disposal
- service interval and what happens when service is missed
- how low-power states are communicated before failure
Power management should prevent surprise failure. A device that dies silently creates more support burden than a device that warns early, preserves core function, and records why it degraded.
Use Figure 22.6 to separate nominal capacity from usable energy. Battery, charging, and service evidence should include derating, reserve, access, and the failure mode when the service interval is missed.
22.14 Power And User Experience
Power behavior is part of the product experience.
Review:
- whether users can understand charge, battery, or service state
- whether low-power behavior degrades gracefully
- which function remains available when power is limited
- whether notifications are timely and actionable
- whether frequent charging or replacement conflicts with the deployment context
- whether power-saving settings change data quality, safety, or reliability
- whether the device recovers cleanly after charging, replacement, or brownout
The review should distinguish hidden power savings from user-visible tradeoffs. Reducing sample frequency, disabling live status, delaying uploads, or limiting actuation can be valid, but those changes must be visible in the power record.
22.15 Update-Energy Gate
OTA and configuration changes require extra power evidence.
Before an update, review:
- current battery, charging, or external power state
- expected energy for download, verify, write, reboot, and rollback
- storage available for package and fallback state
- whether the device can defer updates during low-power or critical operation
- whether a failed update leaves the previous firmware usable
- post-update health evidence
An update path that works on a charger may not be acceptable for a sealed field device. The update gate should make the difference explicit.
22.16 Power Readiness Record
Figure 22.7 shows the fields to preserve:
- Power source: battery, mains, charging, harvesting, backup, or mixed source.
- Measured states: current and duration for sleep, idle, sensing, compute, transmit, receive, display, actuation, and update.
- Duty cycle: wake sources, frequency, duration, retry rules, heartbeat, and exception behavior.
- Connectivity energy: join, listen, send, acknowledge, retry, gateway, and installed signal evidence.
- Battery and service: usable capacity, temperature, aging, self-discharge, charge or replacement, and access.
- Low-power UX: warning, degraded function, user control, support state, and recovery.
- Update gate: energy, storage, compatibility, rollback, deferral, and post-update health.
- Decision and change condition: accepted tradeoff, owner, known limit, open issue, and condition requiring another review.
The record should remain short enough to update when firmware, schedule, radio, enclosure, or deployment changes.
22.17 Worked Review: Battery Sensor Endpoint
A battery endpoint measures a slowly changing condition and reports through a gateway.
Power evidence to request
- Measured sleep current with the final firmware and peripheral configuration.
- Measured wake, sensor, compute, transmit, receive, and return-to-sleep durations.
- Reporting schedule, heartbeat rule, and retry behavior.
- Gateway dependence and installed link evidence.
- Battery usable-capacity assumption in the intended temperature range.
- Low-battery notification and service path.
- Update deferral rule when battery is low.
- Change condition after sensor, radio, battery, firmware, enclosure, or gateway changes.
Likely review action
Hold the decision if the record says “multi-year battery life” but shows only a nominal battery capacity and a datasheet sleep value. The design needs measured state evidence and a service assumption.
Change condition
Rerun the review when wake frequency, radio retry policy, gateway distance, sensor mode, firmware build, battery chemistry, enclosure temperature, service interval, or update policy changes.
22.18 Worked Review: Interactive Device
An interactive connected device has a display, local controls, and an actuator.
Power evidence to request
- Idle connected behavior and display or indicator policy.
- User interaction frequency and time spent in high-power states.
- Actuator load, safe-state behavior, and brownout recovery.
- Charging or replacement workflow that users can complete.
- Low-power behavior that preserves the most important function.
- Logs that distinguish low power from network failure or mechanical failure.
- Update gate that avoids disrupting critical use.
Likely review action
Ask for a user-facing power record if the device depends on frequent charging, warning banners, reduced features, or manual recovery. Those are UX decisions, not only engineering details.
Change condition
Rerun the review when display behavior, actuator load, notification policy, charging hardware, user workflow, firmware update policy, or low-power threshold changes.
22.19 Common Findings
- Battery life is claimed from nominal capacity instead of measured state evidence.
- The power boundary ignores a gateway, charger, battery pack, cable, or maintenance dependency.
- Sleep current was not measured with the final firmware and peripherals.
- Connectivity energy ignores join time, listening, acknowledgements, retries, or weak-signal behavior.
- The power budget excludes displays, indicators, actuators, sensors, regulators, or debug hardware.
- Low-battery behavior is not visible to users or support staff.
- OTA updates can start without enough energy or a rollback path.
- Service interval depends on access, tools, or user behavior that is not recorded.
- Temperature, storage, aging, or self-discharge assumptions are missing.
- The record lacks an owner, known limit, open issue, or change condition.
22.20 Review Checklist
Before accepting a connected-device power decision, confirm that the record includes:
- power source, backup source, power boundary, and service access
- measured current and duration for all relevant power states
- duty cycle, wake source, heartbeat, retry, and exception behavior
- radio or wired connectivity energy in the installed context
- battery, charging, temperature, aging, storage, and self-discharge assumptions
- display, indicator, actuator, sensor, regulator, and peripheral loads
- low-power user experience, degraded function, support state, and recovery
- update-energy gate, deferral rule, rollback, and post-update health check
- accepted tradeoff, owner, known limit, open issue, and change condition
22.21 Knowledge Check
22.22 Matching Quiz
22.23 Ordering Quiz
22.24 Summary
Connected-device power management is an evidence problem. The review ties measured power states, duty cycle, connectivity energy, battery or charging assumptions, service access, low-power UX, and update gates to the claimed service interval.
The strongest power records avoid generic claims. They show what was measured, what was assumed, what users or technicians must do, what happens at low power, who owns the tradeoff, and what change requires another review.
22.25 Key Takeaway
Power management is a UX constraint: battery life, charging, sleep behavior, and low-power feedback shape whether users trust the device.
22.26 Concept Relationships
- Connected Device Fundamentals defines the device role and boundary that power evidence must match.
- Device Form Factors constrains battery volume, charging access, heat, sealing, and serviceability.
- Device Lifecycle Management connects power evidence to updates, maintenance, transfer, and retirement.
- Energy Aware Considerations expands power review into system-level energy design.
22.27 What’s Next
Continue to Connecting Together to review how connected devices join networks, gateways, and ecosystems without hiding power, setup, or maintenance tradeoffs.