Sleep Mode Optimizer

Sleep Mode Optimizer

Tune IoT sleep and wake choices, then see how current, latency, and duty cycle change battery life.

simulation
power
sleep-modes
battery
duty-cycle
energy
beginner
A beginner-first sleep mode optimizer with animated wake/sense/transmit/sleep cycles, average-current calculation, battery-life projection, break-even checks, and technical accuracy notes.
Simulation Beginner Sleep Modes Battery Life

Sleep Mode Optimizer

Explore how wake, sensing, reporting, and sleep contribute charge over a repeated device schedule. The tool estimates average current and load-only battery life. It does not by itself verify RAM retention, wake-source support, battery pulse capability, or real-board current.

Illustrative model: The supplied mode profiles are teaching examples, not MCU specifications. For design work, replace their current and wake values with named datasheet or measured whole-device values.
Deep sleepselected sleep mode
0 µAaverage current over the supercycle
0 daysload-only battery estimate
Checkingmodelled-check result
Try

Battery life depends on how long the device stays in each state, not only the lowest current number.

Observe

Deep modes may save current but add wake delay, reinitialization time, and missed-event risk.

Explain

Short sleep current gains can be overwhelmed by frequent high-current transmissions.

Boundary

Datasheet currents are starting points; peripherals, pull-ups, sensors, and firmware change real sleep current.

1

Wake

The clock or event source brings the device out of sleep, with mode-specific latency.

2

Sense

The MCU and sensor are active while data is sampled, checked, or buffered.

3

Transmit

Radio bursts are short but usually draw much more current than sensing.

4

Sleep

The device waits in the selected low-power mode for most of the cycle.

5

Validate

The strategy is judged against battery life, latency, and break-even time.

Mean Awake Duty0%Awake share across the full reporting supercycle.
Supercycle Charge0 µAhCharge used by N sensing cycles with one physical report.
Wake/Restore0 msEntered latency before useful work can begin.
Wake-only Break-even0 msNamed comparison against the Light profile.

Controls

Field sensor
Scenariodevice goal
Sleep Modelow leakage
Viewcycle timeline
PlaybackWake
Timingcycle setup
Longer intervals usually make sleep current matter more.
Firmware and sensor warm-up time increase active charge.
Radio bursts are short but high current.
One full report occurs every N sensing cycles. This model assumes the entered report duration already includes the complete batched payload. If a larger batch increases payload airtime, update Radio time per report.
Powerhardware profile
Includes MCU plus sensors while measuring.
For a logger that does not transmit, set Radio time per report to 0 ms. A positive radio duration requires a positive whole-device radio current.
Nominal label capacity; usable capacity is a separate assumption.
This is not an end-to-end application response model.
Mode Profile Evidenceone independent record per mode
Each mode keeps its own values and provenance. The source category does not verify the evidence.
Name the device and datasheet section, or identify the board, firmware, supply, instruments, and setup used for measurement.
Enter battery-side current with the configured peripherals attached.
Set from the chosen cell's discharge curves, temperature, pulse load, cutoff, and regulator requirements.
Percent of nominal capacity per year. The model converts this to a constant equivalent current, Cnominal × r / 8760. It is not exponential decay or a battery-chemistry model.

Wake/sleep cycle

charge use across one interval
Table 1: Current plot data
Mode Profile source Schedule Average current Wake/restore Latency check
wake overhead sense/process radio report sleep wait
Cycle timingThe interval is divided into wake, active work, optional radio, and sleep.
Average currentEach state contributes current multiplied by time.
Design checkThe result must meet response and break-even constraints.

Diagnosis

balanced
Candidate under review The entered schedule has not yet been checked.
Evidence sourceIllustrative
Evidence detailIoTClass teaching default
Sleep current0 µA
Wake time0 ms
Normal-cycle sleep0 s
Report-cycle sleep0 s
Wake + sense charge0 µAh
Radio charge0 µAh
Sleep charge0 µAh
Usable battery0 mAh
Planning lifeself-discharge off
Self-discharge equivalentdisabled
Next actionValidate
Deep sleep usually wins for long intervals, but not when wake latency or wake overhead breaks the requirement.

Average Current

Average current is the charge used by every state divided by the full schedule duration.

Iavg = Σ(Istate × tstate) / Tsupercycle

Battery Life

This is a load-only estimate. Usable capacity is an explicit planning assumption, not a universal 80% rule.

life hours = usable mAh / Iavg

Physical Batching

One full report occurs every N sensing cycles; the timeline never draws a fractional transmission.

Qsuper = (N − 1)Qnormal + Qreport

Break-even

A deeper mode pays back only after extra wake/restore charge is recovered through lower sleep current.

sleep time > extra transition charge / saved current
Sleep Mode Quick Reference

These are mode families, not universal MCU specifications. Mode names, retained state, wake sources, current, and wake time differ by device and configuration.

Mode family Qualitative state Design question Required evidence
Idle or wait CPU execution pauses while many clocks or peripherals may remain powered. Is near-immediate response required? Named-device current, enabled clocks, peripheral state, interrupt latency.
Retention or light sleep Selected state and domains remain powered. Which RAM, clocks, and wake sources must survive? Retention configuration, wake-source matrix, measured resume time.
Deep sleep or standby More power domains are disabled. Is restart and reinitialization acceptable? Retained state, wake cause, boot/restore charge, board sleep current.
Shutdown or hibernate Only a minimal always-on domain remains. Can the system recover from a restart-like wake? Off current, allowed wake pins, state recovery, startup reliability.
Wake Source Selection

A wake source is valid only when the selected device mode, pin or peripheral configuration, and firmware path support it. Confirm the wake-source matrix in the named device reference manual and verify it on the real board.

  • Timer or RTC wakes suit periodic sensing.
  • GPIO wakes suit buttons, reed switches, alarms, and simple external events.
  • Accelerometer wake can save MCU current but adds sensor standby current.
  • Continuous receive, periodic listen windows, protocol paging, preamble sampling, and a separate wake-up receiver have different power behaviour; “radio wake” is not one universal mechanism.
Technical Accuracy Notes
  • Average current is calculated from every state’s current multiplied by duration, then divided by the full N-cycle supercycle.
  • Reporting every 10 cycles means nine sensing cycles without radio and one cycle with the full entered radio duration. The model does not derive packet length or protocol airtime from batch size; the entered radio duration defines the complete physical report cost.
  • Wake/restore current and duration are explicit inputs. Real traces may contain separate entry, oscillator, sensor warm-up, and restore states.
  • The usable-capacity factor is visible and editable. The optional self-discharge input is a constant percentage of nominal capacity per year, not exponential decay or a chemistry model. Battery chemistry, temperature, pulse current, cutoff voltage, regulator dropout, and aging can change real results.
  • The break-even result is a wake-only comparison against the independently sourced Light profile. Each profile has its own sleep current, wake/restore current, and wake/restore duration. Entry energy, oscillator start-up, sensor warm-up, and other restore states remain outside this approximation unless included in those entered values.
Implementation Checklist
  • Measure sleep current with real firmware and all peripherals connected.
  • Check wake sources still work in the selected mode.
  • Verify wake latency against event timing and communication windows.
  • Batch transmissions where the application permits stale data.
  • Test brownout and recovery behavior near end-of-life battery voltage.

Find The Break-even Point

Set the wake interval to 2 seconds and compare Light, Deep, and Hibernate. Notice when Hibernate’s wake cost is paid too often.

Radio Dominates

Select Asset Tracker, set Report Every to 1, then increase radio time. Notice how sleep-current gains become less important.

Wake-Latency Constraint

Select Door Alert and lower Maximum wake/restore latency. Hibernate becomes a poor choice even though its sleep current is lowest.

Battery Life Estimator

Model full device profiles with battery capacity and transmit patterns.

 Power Budget Calculator

Break down component-level current draw and budget margins.

 Energy Harvesting Analysis

Compare harvested energy with low-power consumption.
Sleep optimizer · retention break-even

Which sleep state is cheapest for this wake interval?

Compare retained standby with cold shutdown across oscillator start, state restore, useful work, and the remaining sleep window.

TryStart at 1.00 s. Change only Wake interval to 10.0 s.
ObserveThe winner flips because restart cost is paid once while sleep leakage accumulates.
ExplainDeepest sleep wins only beyond the break-even interval—and response latency still matters.

Try the chooser

Logarithmic: 10 ms to 1 h.
Logarithmic: 1,000 to 100M cycles.

Edit one mode profile

1 · OscillatorRestart clocks at the selected mode current.
2 · Run + restoreComplete retained or cold-start work cycles.
3 · Sleep + compareAccumulate leakage, then choose whole-cycle energy.
Retained standby winsAt 1.00 s, retained standby costs less whole-cycle energy.
0.00330 mJoscillator energy
0.990 mJrun + restore energy
0.148 mJsleep energy

Observe the evidence

Active current3.00 mA
Standby cycle1.14 mJ
Shutdown cycle1.22 mJ
Standby latency100 ms
Shutdown latency115 ms
Standby average1.14 mA
Shutdown average1.11 mA
Break-even interval—
Misconception flip. “The deepest sleep is always cheapest.” Change only Wake interval from 1.00 s to 10.0 s: the winner reverses from standby to shutdown.
RunIactive = Istatic + slope × f
trun = 1000 × (work + restore)/(f × 10^6)
Whole cycleEcycle = Eosc + Erun + Esleep
Iaverage = 1000 Ecycle/(V × interval)
Break-evenT = 1000(KA − KB)/(Psleep,B − Psleep,A)
Technical boundaries. Currents and restart costs are entered evidence, not MCU-family claims. The model uses a linear active-current/clock relation and fixed work-cycle count. It does not simulate voltage/frequency tables, cache miss distributions, flash wait states, peripherals, DVFS transition loss, oscillator tolerance, battery chemistry, thermal limits, or deadlines beyond the displayed response latency. Measure a real whole-device trace before release.

Rank-3 fixture self-test pending.