Chapters

16 WSN Duty Cycle Worked Examples

iot
wireless-sensor-networks
duty-cycling

16.1 Start With the Field Story

This section: Start With the Field Story — Treat each duty-cycle example as a small energy ledger.

Treat each duty-cycle example as a small energy ledger. List the states, attach a current draw and time share to each one, include wake and communication overhead, then ask whether the resulting average current matches the lifetime claim.

16.2 In 60 Seconds

This section: In 60 Seconds — Duty-cycle examples are useful when each calculation is tied to an evidence record.

Duty-cycle examples are useful when each calculation is tied to an evidence record. A reviewable example lists the states, current draw, active interval, cycle length, omitted overhead, average-current result, and retest trigger.

This chapter uses supplied exercise values only. The goal is not to promise an operating interval for a particular node. The goal is to show how to check a duty-cycle claim, find missing states, and write a bounded decision.

The mathematical gist. The chapter’s 160-bit, 24 mA transmit at 4,000 bit/s lasts 40.0 ms and spends 960 mA·ms. A catalog-typical depleted CR2032 sags 0.480 V to 2.52 V, only 0.12 V above a 2.4 V brownout line. After explicit retention, cold, and cutoff factors, 157 mAh at the chapter’s 0.213 mA average gives about 739 h or 30.8 days. Charge, energy, voltage sag, and airtime are separate checks.

Math Bridge · guided foundationsWill the radio survive its 24 mA burst, not just average it?Let Packet Pete turn payload bits into airtime, sag, usable charge, and bounded runtime.

16.3 Learning Objectives

This section: Learning Objectives

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

  • Build a state ledger for a duty-cycled sensor node.
  • Compute average current from active, wake, transmit, listen, and sleep states.
  • Solve for a cycle length from a current budget.
  • Compare a simple calculation with a measured trace and explain the gap.
  • Record validation evidence and retest triggers for duty-cycle examples.

16.4 Quick Check: Duty Cycle Worked Examples

This section: Quick Check: Duty Cycle Worked Examples

16.5 Minimum Viable Understanding

This section: Minimum Viable Understanding — Duty cycle is an active fraction, but average current depends on every state in the cycle.

Duty cycle is an active fraction, but average current depends on every state in the cycle. Sleep current is small per instant but can dominate a long cycle. Wake, listen, guard, and transmit states should not be hidden inside a single active number. A current budget can be used to solve for the minimum cycle length needed to stay under a maximum average-current budget. Weighted mode examples must state how much of the record is spent in each mode. A calculation is not accepted until the record states what was measured, assumed, and excluded.

16.6 Prerequisites

This section: Prerequisites

16.7 Review Pattern

This section: Review Pattern — Worked examples matter because duty-cycle decisions usually fail in the gap between a neat percentage and an operating record.

Worked examples matter because duty-cycle decisions usually fail in the gap between a neat percentage and an operating record. Treat each example as a small audit trail: follow the numbers, then ask what the calculation proves, what it leaves out, and what field evidence would confirm that the schedule is still acceptable.

Each worked example should produce a short review record:

Question: what claim is being checked? State ledger: which states occur in one cycle? Inputs: current draw, active interval, cycle length, and units. Calculation: current-time sum divided by the full cycle length. Evidence: trace, log, or inspection that supports the inputs. Decision: accept, revise, or retest. Retest trigger: the change that makes the calculation stale.

Make Review Pattern testable with the visual in Figure 16.1. The Duty-Cycle Worked Example: State Ledger and Exercise question checkpoints frame the evidence behind Review Pattern.

Duty-cycle worked example state ledger showing the exercise question, a state list where sensing is 960, transmit 960, wake 60, and sleep 148.05 mA·ms, a current-time sum of 2,128.05 mA·ms divided by the 10,000 ms cycle, a 0.213 mA average, an evidence check, and a decision note.
Figure 16.1: Duty-cycle worked example state ledger (Example 1): sensing, transmit, wake, and sleep terms sum to 2,128.05 mA·ms, divided by the 10,000 ms cycle for a 0.213 mA average.

Figure Figure 16.1 shows why a duty-cycle claim needs a full state ledger. The exercise begins with a claim that counts sensing and transmit alone. The table adds wake and sleep, with each interval, current, and current-time term visible. Those four terms sum to 2,128.05 mA·ms; dividing by the full 10,000 ms cycle gives 0.213 mA average current. The evidence check asks for a trace that confirms wake and sleep, and the decision note revises the original claim. This links the arithmetic to the review pattern: name the claim, show every state, check the inputs, and record the decision.

Concrete example context: treat each exercise as a review of a battery-powered status node, such as a leak detector or soil-moisture node, before its schedule is accepted for a field trial. The arithmetic is useful only because the ledger explains what the node actually does during wake, sense, listen, transmit, and sleep states.

16.8 Example 1: Expand A Simple Cycle

This section: Example 1: Expand A Simple Cycle — A learner claims that a node uses only its sensing and transmit states during a repeating cycle.

Question

A learner claims that a node uses only its sensing and transmit states during a repeating cycle. Check the average-current result after adding wake and sleep states.

Given exercise record

  • Sensing state: 80 ms at 12 mA.
  • Transmit state: 40 ms at 24 mA.
  • Wake overhead: 10 ms at 6 mA.
  • Sleep state: remaining interval at 0.015 mA.
  • Full cycle length: 10,000 ms.

Step 1: compute the known current-time terms

sensing  = 80 ms  x 12 mA  = 960 mA*ms
transmit = 40 ms  x 24 mA  = 960 mA*ms
wake     = 10 ms  x 6 mA   = 60 mA*ms

Step 2: compute the sleep interval

sleep interval = 10,000 ms - 80 ms - 40 ms - 10 ms
sleep interval = 9,870 ms
sleep term     = 9,870 ms x 0.015 mA = 148.05 mA*ms

Step 3: divide by the full cycle length

current-time sum = 960 + 960 + 60 + 148.05
current-time sum = 2,128.05 mA*ms
average current  = 2,128.05 / 10,000
average current  = 0.213 mA

Decision

Revise the original claim if it omitted wake or sleep states. The corrected average current for this exercise record is 0.213 mA.

Retest trigger

Repeat the review if any state interval, current draw, cycle length, or radio behavior changes.

16.9 Example 2: Solve For The Cycle Length

This section: Example 2: Solve For The Cycle Length — A review record gives the maximum average current as 0.080 mA.

Question

A review record gives the maximum average current as 0.080 mA. Determine the cycle length that keeps the example at or below that budget.

Given exercise record

  • Wake state: 15 ms at 8 mA.
  • Sensing state: 120 ms at 10 mA.
  • Transmit state: 60 ms at 28 mA.
  • Sleep current: 0.012 mA.
  • Maximum average current: 0.080 mA.

Step 1: compute active current-time sum

wake     = 15 ms  x 8 mA  = 120 mA*ms
sensing  = 120 ms x 10 mA = 1,200 mA*ms
transmit = 60 ms  x 28 mA = 1,680 mA*ms
active current-time sum = 3,000 mA*ms
active interval = 195 ms

Step 2: solve for cycle length

Let T be the full cycle length in milliseconds.

0.080 = (3,000 + 0.012 x (T - 195)) / T
0.080T = 3,000 + 0.012T - 2.34
0.068T = 2,997.66
T = 44,083 ms

Step 3: interpret the answer

The cycle length must be at least about 44.1 s for the supplied values to meet the current budget. A shorter cycle can still work if another state is reduced, but that new design needs its own record.

Decision

Accept the schedule only if the implementation actually uses a cycle length at or above the computed value and the trace confirms the listed states.

Retest trigger

Repeat the review if the current budget, active interval, transmit interval, or sleep current changes.

16.10 Example 3: Weighted Modes

This section: Example 3: Weighted Modes — A node has three operating modes during an observation record.

Question

A node has three operating modes during an observation record. Compute the weighted average current and decide whether the record supports the current budget.

Given exercise record

  • Baseline mode: fraction 0.80, average current 0.050 mA.
  • Watch mode: fraction 0.15, average current 0.200 mA.
  • Event mode: fraction 0.05, average current 1.000 mA.
  • Current budget: 0.150 mA.

Step 1: multiply each mode by its fraction

baseline contribution = 0.80 x 0.050 mA = 0.040 mA
watch contribution    = 0.15 x 0.200 mA = 0.030 mA
event contribution    = 0.05 x 1.000 mA = 0.050 mA

Step 2: add the contributions

weighted average current = 0.040 + 0.030 + 0.050
weighted average current = 0.120 mA

Decision

Accept the calculation for the supplied observation record because 0.120 mA is below the 0.150 mA budget. The decision is bounded to the stated mode fractions.

Retest trigger

Repeat the review if event mode becomes more common, if any mode current changes, or if the mode classification rule changes.

16.11 Example 4: Explain A Measurement Gap

This section: Example 4: Explain A Measurement Gap — A simple ledger predicts 0.210 mA, but a measured trace shows 0.300 mA.

Question

A simple ledger predicts 0.210 mA, but a measured trace shows 0.300 mA. Find a plausible missing state before changing the schedule.

Given exercise record

Simple ledger result: 0.210 mA. Measured trace result: 0.300 mA. Full cycle length: 10,000 ms. Trace inspection finds a guard-listen state: 60 ms at 15 mA.

Step 1: compute the missing guard-listen contribution

guard-listen term = 60 ms x 15 mA = 900 mA*ms
guard-listen average contribution = 900 / 10,000
guard-listen average contribution = 0.090 mA

Step 2: add it to the simple ledger

corrected average current = 0.210 mA + 0.090 mA
corrected average current = 0.300 mA

Decision

The measured trace is consistent with the missing guard-listen state. Revise the ledger rather than treating the measurement as a fault.

Retest trigger

Repeat the review if guard-listen length, synchronization policy, radio state, or cycle length changes.

Use Figure 16.2 to find which omitted radio state explains the gap between the ledger and the measured trace.

Duty-cycle worked example review loop with six stages: state ledger, calculation, trace comparison, gap explanation, revised decision, and retest trigger, with the Example 4 arithmetic where a 60 ms by 15 mA guard-listen adds 0.090 mA to reconcile a 0.210 mA ledger with a 0.300 mA trace.
Figure 16.2: Duty-cycle worked example review loop: six stages with the Example 4 guard-listen arithmetic that closes a 0.210-to-0.300 mA gap.

Start with the state ledger, then compare its predicted current with the trace rather than treating either value as automatically correct. The gap is 0.300 mA - 0.210 mA = 0.090 mA. The guard-listen state supplies exactly that average: 15 mA × 60 ms / 10,000 ms = 0.090 mA. Add that missing state, recompute the total, and record why it was absent. The final retest trigger matters because a change to the guard interval, radio current, or cycle time invalidates the reconciliation.

16.12 Example 5: Budget A Multi-Component Device

This section: Example 5: Budget A Multi-Component Device — The first four examples ledger one radio’s states inside a single repeating cycle.

Question

The first four examples ledger one radio’s states inside a single repeating cycle. A field device usually has several independently switchable subsystems instead of one radio, and the record has to show which combination of subsystems is active, not just how long any one of them runs. A cold-chain tracker tag has temperature, vibration, humidity, and light sensors plus a Bluetooth Low Energy (BLE) radio, a GPS receiver, and an LTE radio, each of which can be on or off separately. Compare four operating modes and decide which ones meet a 30-day shipment requirement.

Given exercise record

  • Battery: a 0.2 Wh coin cell (the record’s whole usable-energy budget for the trip).
  • Always-on sensor draw (temperature, vibration, humidity, light together): 0.199 mW.
  • BLE beacon: 10 ms of radio-on time once per hour.
  • GPS fix: 10 s of radio-on time once every 3 hours.
  • LTE upload: 50 ms of radio-on time once every 24 hours.
  • Mode A — System on: every subsystem left active continuously, measured at 2,180.66 mW.
  • Mode B — Sensors only: sensors active, BLE/GPS/LTE off, measured at 0.199 mW.
  • Mode C — Sensors + BLE beacon: the stated 10 ms transmit event once per hour uses the TI CC2652R 3 V, 0 dBm transmit reference of 7.0 mA, adding 0.0000583 mW on average (datasheet). This is a transmit-only estimate: startup energy is not given, and the example assumes the radio is fully off between beacons with no standby or receive/listen time.
  • Mode D — Sensors + BLE + GPS + LTE: adds the periodic GPS fix and daily LTE upload; the original C/D readings imply an unverified 0.199 mW GPS/LTE increment.

Step 1: convert each mode’s average power to a lifetime

lifetime (hours) = battery energy (Wh) / average power (W)
Mode A: 0.2 Wh / 2.18066 W   = 0.0917 h  = 5.5 minutes
Mode B: 0.2 Wh / 0.000199 W  = 1,005 h   = 41.8 days
Mode C: 0.2 Wh / 0.0001990583 W = 1,004.7 h = 41.9 days
Mode D: 0.2 Wh / 0.0003980583 W =   502.4 h = 20.9 days

Step 2: read the ledger as a budget, not a single number

For the BLE transmit-only estimate, 7.0 mA × 3 V × 0.010 s / 3600 s = 0.0000583 mW average; this is the added hourly transmit energy, not a complete beacon energy measurement. Mode D carries forward the same 0.199 mW GPS/LTE increment as the supplied difference between the original C and D readings, pending a state-by-state measurement of GPS fix and LTE connection, upload, and receive phases. Thus the recomputed Mode C and D lifetimes are optimistic energy bounds: record BLE startup energy and any standby or receive/listen intervals, then replace the transmit-only estimate before accepting either mode. Mode A represents every sensor, the BLE radio, the GPS receiver, and the LTE modem left running. Dividing 0.2 Wh by 2,180.66 mW gives a five-and-a-half-minute ideal energy bound, not a feasible coin-cell operating mode. For context, a CR2032 is specified at 3 V and 0.2 mA continuous drain (Panasonic datasheet); check the selected cell’s continuous-drain rating and its voltage sag under each peak load, since a nominal energy quotient alone cannot show that the source can supply the load.

Decision

For a shipment leg that must report location and status for at least 30 days, Mode B’s 41.8 day sensor-only estimate clears the energy budget but has no telemetry. Mode C’s 41.9 day transmit-only estimate is not yet an acceptance result because BLE startup and any standby or receive/listen energy are missing; accept it only after those states and the required reporting path are measured and the peak-current test passes. Mode D’s recomputed 20.9 day estimate misses 30 days even before the BLE and GPS/LTE omissions are resolved. If BLE alone cannot meet the tracking requirement, the design needs a different reporting path, a lower measured GPS/LTE energy cost, a suitable larger power source, or a shorter accepted shipment leg.

Retest trigger

Repeat the review if the GPS fix interval, LTE upload interval, BLE beacon interval, sensor set, or battery capacity changes, and re-measure rather than reuse these currents if the tag design or firmware changes.

What this example adds: Examples 1-4 ledger one radio's states inside a single repeating cycle. This example ledgers several independently switchable subsystems (sensors, BLE, GPS, LTE) at the operating-mode level, so the record can show which combination of subsystems -- not just which single duty cycle -- meets a multi-week field requirement.

16.13 Review Checklist

This section: Review Checklist — Is the question stated?

Before accepting a duty-cycle worked example, check:

Is the question stated? Are all state intervals listed with units? Are current values recorded in a consistent unit? Does the calculation divide by the full cycle length? Are wake, listen, guard, and transmit states included when present? Is the evidence source named? Is the decision bounded to the supplied record? Is the retest trigger explicit?

16.14 Knowledge Check

This section: Knowledge Check

16.15 Matching Quiz

This section: Matching Quiz

16.16 Ordering Quiz

This section: Ordering Quiz

16.17 Duty Cycle Becomes A Battery-Life Claim

This section: Duty Cycle Becomes A Battery-Life Claim — Duty-cycle arithmetic is useful only when it stays tied to the review record.

Duty-cycle arithmetic is useful only when it stays tied to the review record. The short chain is: a duty cycle sets an average current, average current divided into battery capacity gives lifetime, and the evidence record states which states were included or excluded. A node that sleeps 99% of the time may move from days to years of operation, but only if the ledger includes wake, listen, transmit, and sleep behavior instead of just the headline active fraction.

Read Figure 16.3 to see why a small active fraction can change a battery estimate by orders of magnitude.

Duty cycle impact on battery life comparing an always-on device with 20 mA average current lasting days against a 1% duty cycle device whose low average current lasts far longer.
Figure 16.3: Duty cycle impact on battery life: for a 2000 mAh battery, always-on versus a 1% duty cycle changes the average current and extends lifetime from days to years.

Begin with the always-on branch, where the load draws 20 mA throughout the cycle. A 2000 mAh battery therefore gives an ideal life of 2000 mAh / 20 mA = 100 h, or about four days. The duty-cycled branch moves most time into sleep, so its average current is far below the active current and the estimate stretches toward years. That comparison is only a planning bound: wake-up, listening, self-discharge, temperature, and battery derating still belong in the state ledger before the lifetime claim is accepted.

Read the ledger left to right: name the state, multiply current by time, add every contribution, and divide by the full period. The formula is reviewable only when the state rows are visible.

The same average-current ledger can support an operating-life estimate, but the estimate inherits every assumption in the ledger. A field note that says “2% duty cycle” is not enough if the node also wakes an oscillator, waits through a guard interval, listens for a parent, retries a transmit, or leaves a sensor rail biased after the sample.

For a novice, the easiest mental model is a phone that spends most of the day with its screen off. The screen-off time helps, but the phone still drains if background radios, sensors, or apps keep running. A sensor node is the same kind of accounting problem at smaller currents. The ledger is not extra paperwork; it is the place where hidden always-on behavior becomes visible. If the ledger says “sleep” but a pull-up, regulator, or sensor bias remains on, the battery-life claim is already optimistic.

That is why the worked examples in the body stop at bounded decisions instead of announcing a universal lifetime. Each arithmetic answer is a claim about one record, one set of states, and one evidence source. When the hardware or schedule changes, the record must be rerun before the lifetime story is reused.

16.18 Average Current To Lifetime

This section: Average Current To Lifetime — Then lifetime = battery capacity / I_avg.

Average current blends the active and sleep states weighted by duty cycle D:

I_avg = D x I_active + (1 - D) x I_sleep

Then lifetime = battery capacity / I_avg. Take a node with I_active = 20 mA, I_sleep = 5 uA, a 2000 mAh battery, and a 1% duty cycle:

StepValue
Active contribution0.01 x 20 mA = 0.20 mA
Sleep contribution0.99 x 0.005 mA ~= 0.005 mA
Average current~= 0.205 mA
Lifetime2000 mAh / 0.205 mA ~= 9750 h ~= 1.1 years

Two practical details keep this calculation honest. First, the units must agree: battery capacity in mAh divided by average current in mA gives hours, not seconds or cycles. Second, the capacity number is not a perfect fuel tank. Temperature, battery chemistry, regulator efficiency, cutoff voltage, pulse current, and ageing can reduce usable capacity, so a production record should treat the arithmetic lifetime as an upper-bound estimate unless the battery test supports it.

The calculation also tells the practitioner which measurement to improve next. If active current dominates, shortening transmit time or reducing radio current can move the result. If sleep current dominates, a better active routine may barely matter; the useful work is finding leakage, sleep-mode mistakes, or always-on peripherals. A reviewable example names that controlling term so the next lab measures the right state instead of repeating the same average-current calculation.

The same node at 100% duty draws 20 mA and lasts about 100 hours, roughly four days. Dropping to a 1% duty cycle multiplies lifetime by nearly 100x, but the decision is still bounded to this battery, this active current, this sleep current, and this duty cycle. If any of those terms changes, the lifetime estimate needs a new record.

Practitioner check: when a worked example solves for cycle length, state the result as a constraint, not a promise. “At least 44.1 s for this ledger” is reviewable; “the node lasts long enough” is not.

16.19 Sleep Current Sets The Floor

This section: Sleep Current Sets The Floor — Look again at the numbers as the duty cycle keeps falling.

Look again at the numbers as the duty cycle keeps falling. At 1% duty the active term (0.20 mA) still dominates the sleep term (0.005 mA). At 0.01% duty the active contribution drops to about 0.002 mA, below the 0.005 mA sleep current. Beyond that point, cutting the duty cycle further barely helps because the node’s lifetime is set by what it draws while asleep. Sleep current becomes the floor on average current, and therefore the ceiling on battery life.

This reframes low-power engineering. Once your duty cycle is very low, the payoff moves from “wake less often” to “sleep more deeply”: a microcontroller sleep mode of 5 uA versus 50 uA changes the lifetime floor by 10x at those duty cycles, while shaving the active time does almost nothing. It also explains why designers scrutinize leakage, brown-out circuitry, and always-on peripherals: at aggressive duty cycles, the microamps you cannot switch off are the whole game. The worked numbers are not just a lifetime estimate; they tell you which parameter to optimize next.

Worked example: the crossover point. The active term equals the sleep term when D x Iactive = (1 - D) x Isleep. With Iactive = 20 mA and Isleep = 0.005 mA, the crossover is approximately D = 0.005 / (20 + 0.005) = 0.00025, or 0.025%. Above that duty cycle, the active burst is still the larger contributor. Below it, sleep current dominates. A 0.01% duty cycle is below the crossover, so a designer should first audit leakage, sleep-mode selection, regulator quiescent current, pull-up paths, and sensors left biased during sleep.

The floor also explains why measurement traces can disagree with tidy ledgers. A meter set to average current may hide a short 24 mA transmit pulse, while a slow logging interval may miss a 6 mA wake ramp. Conversely, an unexpected 10 uA leakage path can double a nominal 5 uA sleep floor and erase the benefit of rare wakeups. Under the hood, duty-cycle examples are not just algebra: they are a model of where current flows in time, which instrument can see it, and which omitted state would change the final decision.

See why the tempting answer fails.
  1. A cartoon crosses out the wrong claim and shows the section evidence. Wrong idea: cut the tiny active time again because it always drives battery use. It fails because sleep leakage is now larger and sets the current floor.

    Wrong idea: cut the tiny active time again because it always drives battery use. It fails because sleep leakage is now larger and sets the current floor.

A sleeping sensor saves more power by cutting leakage than active time.

16.20 Summary

This section: Summary — Duty-cycle worked examples should preserve the evidence behind the arithmetic.

Duty-cycle worked examples should preserve the evidence behind the arithmetic. A complete review record states the question, lists every state, computes current-time terms, divides by the full cycle length, compares the result with evidence or a current budget, and records a retest trigger. Missing wake, listen, guard, or transmit states are common reasons a simple calculation disagrees with a measured trace.

16.21 Key Takeaway

This section: Key Takeaway — Duty-cycle worked examples should show the energy, latency, sensing, communication, and failure assumptions behind each schedule.

Duty-cycle worked examples should show the energy, latency, sensing, communication, and failure assumptions behind each schedule.

16.22 Concept Relationships

This section: Concept Relationships — Duty Cycle Fundamentals define active fraction and average-current vocabulary.

Duty Cycle Fundamentals define active fraction and average-current vocabulary. State ledgers make each operating state visible. Weighted modes connect adaptive schedules to observed mode fractions. Trace comparison separates missing states from measurement faults. Retest triggers keep calculations tied to the current design record.

16.23 What’s Next

This section: What’s Next — Use WSN Duty Cycling to review sleep/wake scheduling and measurement evidence.

Previous: WSN Duty Cycling

Next: WSN Deployment Sizing

Use WSN Duty Cycling to review sleep/wake scheduling and measurement evidence. Continue to WSN Deployment Sizing to connect energy records with field deployment constraints.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed