6 Low-Power Design: Firmware and Wake Policies

energy-power

aware

low

strategies

6.1 Start With the Decision

A sleeping node can still waste power through a pull-up or sensor rail. Trace each leak before changing firmware.

6.2 Route Overview

This is part 1 of 2. Continue with Low-Power Design: Duty-Cycle Energy Accounting.

6.3 Part Objectives

Measure low-power design strategies from current, time, and transition evidence.
Validate worked policy review with a concrete scenario and pass criteria.

6.4 Overview

This first route builds a complete low-power strategy from service needs through wake policy, duty cycling, load control, radio behavior, and release evidence.

This is part 1 of 2. Continue with Low-Power Design: Sleep Depth and Hidden Leakage for the second focused route.

6.5 Start With the Sleeping Device

Wake Only for Work the Service Still Needs

Picture a battery door sensor that checks the door every second but reports only real changes. Saving power is not simply making everything sleep; the device must still notice the event and preserve its meaning. The first decision is which service promise controls each wake-up.

An application programming interface is a defined way for software parts to request work or data; API is its short name. Firmware means the software stored on a device. Latency means the time from an input event to the result that matters.

Measure sleep current, wake time, active work, message time, and return to sleep. Trigger the door, add a false wake, delay the link, repeat the event, and restart the device. Record missed events, duplicates, age, and energy per useful result.

This runway does not prove that the deepest sleep state is always best. The deeper sections compare service policy, wake sources, state retention, start-up cost, communication delay, measurement, and break-even choices.

The cheapest energy is the energy a device never draws. A low-power design begins by asking what must stay awake, what may sleep, and what event is allowed to wake the system again.

The simple route is service policy first, wake policy second, power states third, and measurement last. If a strategy cannot be seen in the trace, it is still only a claim.

Battery Bruno

“A strategy that isn’t in the trace is still just a claim — show me the charge it actually saved.”

Here Bruno follows the budget past sleep mode, into the radio and clock choices that decide whether the savings survive contact with real firmware.

In 60 Seconds

Low-power design is a sequence of decisions: reduce wake frequency, choose the deepest sleep state that still meets latency and wake-source needs, power-gate unused loads, batch radio work, and validate the final average current with a full-cycle trace.

Phoebe’s Field Notes: The Pull-Up Leak Is Ohm’s Law Plus a Junction, Not Just Ohm’s Law

The mathematical gist. A depowered sensor is not a zero-volt short: its protection diode keeps about 0.6 V, so a 4.7 kOhm pull-up on 3.3 V leaks $(3.3-0.6)/4700=0.574$ mA rather than 0.702 mA. Two lines over 60 s still waste 68.9 mA-s, about 115 times a 10 microamp processor’s sleep charge.

6.6 Low-Power Design Strategies

Low-power design is not a single sleep-mode API call. It is a system policy that controls when the device wakes, what it powers, how long it stays active, and how quickly it returns to a measured low-current state.

This chapter focuses on the decisions that move an IoT node from a plausible budget to a working low-power design: sleep selection, duty-cycle policy, peripheral power gating, firmware timing, radio batching, and measurement discipline.

6.7 Learning Objectives

By the end of this chapter, you will be able to:

Select a sleep mode from wake latency, state retention, and wake-source requirements.
Design time-based, event-driven, and adaptive duty-cycle policies.
Identify hidden loads from GPIOs, pull-ups, regulators, sensors, LEDs, and radios.
Use power gating and state reinitialization without corrupting measurements or firmware behavior.
Decide when batching, filtering, or local processing reduces radio energy.
Explain when clock or voltage scaling helps and when it only stretches active time.
Verify a low-power strategy with a whole-device current trace.

Minimum Viable Understanding

The deepest sleep mode is not always best; wake latency, retained state, and wake-source support matter.
Duty cycling reduces average current only if active work is short and sleep current is actually low.
Peripherals can dominate sleep current unless they are disabled, held in a known state, or power-gated.
Radio energy includes startup, association, receive windows, retries, and acknowledgments, not only transmit current.
Every optimization claim should be checked against a before/after current trace.

Chapter Roadmap

Overview
Start With the Sleeping Device
In 60 Seconds
Phoebe’s Field Notes: The Pull-Up Leak Is Ohm’s Law Plus a Junction, Not Just Ohm’s Law
Low-Power Design Strategies
Minimum Viable Understanding
Strategy Stack
Service Policy
Wake Policy
Power States
Load Control
Sleep-Mode Selection
Checkpoint: Sleep Policy Fit
Duty-Cycle Policies
Time-Based
Event-Driven
Hybrid
Adaptive
Worked Policy Review

Chapter path:

First you choose a sleep state from wake source, wake latency, retained state, and whole-device current instead of from the lowest datasheet number alone.
Then you turn the service requirement into a time-based, event-driven, hybrid, or adaptive duty-cycle policy and keep transition cost in the ledger.
Next you control the loads that stay awake around the MCU: sensors, pull-ups, radios, indicators, rails, and reinitialization steps.
Finally you verify the release with a trace that labels sleep, wake, sensing, radio, retries, and recovery states.

Checkpoints mark the review decisions; the worked policy review, Ada audit, and power budget calculator carry the detailed arithmetic.

At very low duty cycles, silicon leakage sets the floor. MOS transistors do not turn off as ideal switches: subthreshold current falls below the threshold voltage, but it does not become zero. Raising threshold voltage can reduce off current, but it also reduces available on current and can slow the active work that the node is trying to finish quickly.

The chapter roadmap starts with a limit that firmware cannot switch away: transistor leakage. Inspect Figure 6.1 before choosing sleep tactics so the silicon floor stays separate from board-level loads that software can control.

Log drain current versus gate-to-source voltage for a low-VT and a high-VT device. Both curves rise smoothly through a subthreshold region before saturating; neither reaches zero current below its own threshold. The low-VT device saturates earlier and reaches a higher on-current, but also settles at a higher off-current floor. The high-VT device saturates later at a lower off-current floor, but also a lower on-current. — Figure 6.1: A transistor transfer curve on a log scale comparing a low-threshold-voltage device and a high-threshold-voltage device, showing that neither reaches zero current below threshold.

On Figure 6.1, use V_GS as the horizontal control and log(I_DS) as the current scale. Compare the Low V_T curve with High V_T: raising threshold lowers the labelled off-current from I_OFF (low V_T) toward I_OFF (high V_T), but it also lowers available on-current. Neither curve reaches zero below threshold. This trade-off establishes the device floor that the later state, peripheral, and rail strategies must measure around.

Some chip families, including fully depleted silicon-on-insulator processes, expose forward or reverse body-bias modes to shift threshold voltage after fabrication. Treat that as chip-selection evidence rather than a magic firmware setting. Record the supported bias modes, retained state, sleep current, wake time, active-current penalty, and measured board leakage. If the board still leaves regulators, pull-ups, sensors, or debug circuits biased, body bias will not rescue the battery-life claim.

6.8 Strategy Stack

Low-power design works best when decisions are layered from service policy down to board leakage.

Do not reduce strategy stack to a single headline metric. The visual in Figure 6.2 brings policy and latency + data into the same frame, ready for the evidence comparison that follows.

No-panel low-power strategy stack from service policy through wake policy, power states, load gating, and measurement evidence. — Figure 6.2: Low-power strategy stack showing service policy, wake policy, power states, load gating, and measurement evidence.

On the figure at Figure 6.2, read policy as the point that adds a distinct review condition; latency + data then adds a distinct review condition. The separate Wake label exposes the energy consequence, preventing the first two stages from being accepted on their own. The complete reading is that no-panel low-power strategy stack from service policy through wake policy, power states, load gating, and measurement evidence. This distinction carries forward into strategy stack.

6.9 Service Policy

Define reporting interval, latency, data quality, and missed-event tolerance before choosing the sleep mode.

6.10 Wake Policy

Choose periodic wake, event wake, hybrid wake, or adaptive wake based on what the application must notice.

6.11 Power States

Map each firmware state to current, duration, retained memory, and wake source.

6.12 Load Control

Power-gate sensors, radios, indicators, and external circuits when they are not needed.

6.13 Sleep-Mode Selection

Sleep-mode selection is a requirements decision. A mode is viable only if it preserves the state you need, supports the wake source you need, and wakes quickly enough for the service requirement.

The simplified worked example below shows why sleep percentage alone is not enough: every state contributes current multiplied by time. The numerical values are teaching inputs, not MCU specifications.

The chapter now moves from describing sleep-mode selection to checking it. The diagram at Figure 6.3 is the checkpoint because it puts SIMPLIFIED TWO-STATE EXAMPLE beside TRUE-SCALE 100-SECOND TIMELINE, where an unsupported assumption becomes visible.

A proportional 100-second timeline and charge ledger show 1 second at 10 mA contributing 10 mA·s and 99 seconds at 10 µA contributing 0.99 mA·s. Their 10.99 mA·s total gives 109.9 µA average current. With an ideal 1,000 mAh source, the example estimates about 379 days versus 4.2 days always on, or about 91 times longer rather than 1,000 times. — Figure 6.3: Worked average-current example: 1 second active at 10 mA plus 99 seconds asleep at 10 µA produces 109.9 µA average current and about 91 times the ideal load-only lifetime of an always-on 10 mA device—not 1,000 times.

Figure 6.3 anchors its argument at SIMPLIFIED TWO-STATE EXAMPLE, where the diagram adds a distinct review condition. Follow the presented relationship to TRUE-SCALE 100-SECOND TIMELINE (sets the timing constraint) and finish with ACTIVE — 1 s (adds a distinct review condition). In other words, a proportional 100-second timeline and charge ledger show 1 second at 10 mA contributing 10 mA·s and 99 seconds at 10 µA contributing 0.99 mA·s. Their 10.99 mA·s total gives 109.9 µA average current. With an ideal 1,000 mAh source, the example estimates about 379 days versus 4.2 days always on, or about 91 times longer rather than 1,000 times. This closes the visual check required for sleep-mode selection.

Checkpoint: Sleep Policy Fit

Use the worked example to learn weighted averaging. Before accepting a real sleep policy, replace every current and duration with named datasheet or measured whole-device values, then verify retention, wake sources, wake latency, and the complete reporting-cycle trace.

Mode Family

Use When

Watch For

Evidence To Capture

Idle or wait-for-interrupt

Wake must be nearly immediate and peripherals stay active.

Milliamps of standby current can destroy long-life budgets.

Idle current, interrupt latency, peripheral state list.

Light sleep

Frequent wake events need quick resume and retained RAM.

Retained clocks and peripherals may keep current high.

Sleep current, resume time, enabled clocks.

Deep sleep

Wake intervals are seconds to hours and limited state retention is acceptable.

Boot and reinitialization cost may dominate frequent wakes.

Full-cycle trace, wake cause, initialization time.

Shutdown or hibernate

Events are rare and only a small wake circuit must remain alive.

Full reboot, lost state, and limited wake pins.

Off current, wake reliability, state recovery test.

The whole-cycle comparison below turns the state-selection trade-off into a visible energy ledger. Start with the retention-break-even preset: at a 1.00 s wake interval, compare the labelled Oscillator, Run + restore, and Sleep + compare phases for retained standby and cold shutdown.

Walk through the Standby cycle, Shutdown cycle, and Break-even interval readouts together. The comparison makes the causal boundary explicit: oscillator and restore energy are paid once per wake, while sleep leakage grows with the interval. A deeper state is therefore not automatically cheaper, and its displayed response latency remains a separate design constraint.

6.14 Duty-Cycle Policies

Duty cycling controls when the device spends energy. Start with the service requirement, then choose the simplest policy that meets it.

6.15 Time-Based

Wake on a fixed schedule. Use for slow-changing sensing where missing a short event is acceptable.

6.16 Event-Driven

Wake on an interrupt, comparator, sensor threshold, button, or radio event. Use when the event itself defines when work is needed.

6.17 Hybrid

Combine a watchdog timer with event wake. Use when the device must report health even if no event occurs.

6.18 Adaptive

Change the interval based on measured change rate, battery margin, harvested energy, link quality, or operational mode.

Worked Policy Review

A temperature node reports every 10 minutes, but the environment changes slowly overnight.

Start with the required service: no more than 30 minutes between normal reports, and immediate reporting only when temperature crosses an alert threshold. A hybrid policy fits:

Wake every 30 minutes for a health report.
Let a low-power comparator wake the MCU if the threshold is crossed.
Batch routine samples into one radio session.
Record battery voltage and retry count with each report.
Verify that the comparator and pull-up network do not exceed the sleep-current budget.

The policy saves energy because it removes unnecessary scheduled radio sessions while still preserving the alert requirement.

6.19 Continue to the Next Part

Carry this evidence into Low-Power Design: Duty-Cycle Energy Accounting, which begins with Folded Duty-Cycle Math Notes.