9 Duty Cycle Worked Examples
9.1 Learning Objectives
By the end of this chapter, you will be able to:
- Derive battery life estimates: Perform step-by-step energy budget analysis for sensor deployments incorporating all overhead components
- Quantify wake-up overhead: Calculate the fixed energy costs that reduce real-world battery life by 20-50% versus naive predictions
- Design adaptive strategies: Configure multi-tier duty cycles that respond dynamically to environmental conditions and event frequency
- Diagnose synchronization issues: Identify and resolve clock drift problems in coordinated sleep schedules using measured ppm values
- Apply to real scenarios: Execute battery life calculations for fire monitoring, agricultural sensing, and industrial deployment planning
Core concept: Real-world battery life depends on wake-up overhead, synchronization costs, and adaptive strategies—not just the duty cycle percentage. Why it matters: Naive duty cycle calculations overestimate battery life by 20-50%. Including overhead gives accurate predictions for deployment planning. Key takeaway: Always calculate average current including all overhead costs, and consider adaptive duty cycling for applications with variable event rates.
Specialized IoT architectures address unique challenges that general-purpose designs do not handle well. Think of specialized vehicles like fire trucks, ambulances, and snowplows – each is built for a specific job that a regular car cannot do. Similarly, some IoT deployments need specialized designs for extreme power constraints, harsh environments, or unusual communication patterns.
9.2 Prerequisites
Before working through these examples, you should understand:
- Duty Cycle Fundamentals: Basic duty cycle concepts, power states, and protocol comparison
- Wireless Sensor Networks: Network topologies and energy constraints
9.3 Introduction
Duty cycle calculations on paper look straightforward: multiply active current by active time, add sleep current by sleep time, and divide by the total cycle time. In practice, however, real-world deployments consistently fall short of these predictions by 20–50%. This chapter bridges that gap through three detailed worked examples that progressively introduce the factors engineers most commonly overlook.
Each example follows a consistent methodology:
The three examples cover:
- Forest Fire Monitoring – Basic battery life vs. duty cycle analysis with progressive optimization
- Agricultural Adaptive Cycling – Reverse engineering a duty cycle from a lifetime target and designing an adaptive strategy
- Synchronization Overhead Diagnosis – Debugging real-world battery drain caused by hidden protocol costs
Meet Sammy the Sensor! Sammy lives in a forest and watches for fires. But Sammy runs on batteries, just like your TV remote control.
If Sammy kept his eyes open ALL the time (100% duty cycle), his batteries would die in just 3 days! That is like leaving your flashlight on all night – the batteries run out fast.
So Sammy learned a trick: take a nap! He closes his eyes for a long time, then wakes up for just a tiny moment to check the temperature. This is called duty cycling.
- Eyes open 10% of the time = batteries last about 1 month
- Eyes open 1% of the time = batteries last about 10 months
- Eyes open 0.1% of the time = batteries last over 6 years!
But here is the thing – every time Sammy wakes up, it takes a moment to stretch and get ready (that is the wake-up overhead). Even though checking the temperature only takes a blink, the stretching uses energy too!
The lesson: Sleeping more saves batteries, but you cannot forget about the energy it takes to wake up!
9.4 Worked Example: Forest Fire Monitoring
This worked example demonstrates how duty cycle dramatically affects battery life in a practical deployment scenario, including often-overlooked factors like synchronization overhead and realistic battery capacity.
Context: You are designing a forest fire monitoring network with battery-powered sensor nodes that must operate unattended for at least one year. Each node measures temperature and humidity, then transmits data via a low-power radio to a gateway.
9.4.1 Given Parameters
| Parameter | Value | Notes |
|---|---|---|
| Battery | 2000 mAh (2× AA alkaline) | Typical capacity; usable ~80% due to voltage cutoff |
| Active current | 25 mA | Sensing (5 mA) + Radio TX (20 mA) |
| Sleep current | 10 µA | Deep sleep mode with RTC running |
| Active time per cycle | 100 ms | Sensor read (50 ms) + transmit (50 ms) |
| Sync/wake overhead | 5 ms at 15 mA | Clock sync + peripheral initialization |
| Target lifetime | 1 year minimum | Fire season monitoring requirement |
9.4.2 Solution: Step-by-Step Analysis
Step 1: 100% Duty Cycle (Always On)
In always-on operation, the node continuously monitors and transmits:
\[ I_{avg} = 25 \text{ mA (constant)} \]
\[ \text{Battery Life} = \frac{2000 \text{ mAh}}{25 \text{ mA}} = 80 \text{ hours} = \mathbf{3.3 \text{ days}} \]
Verdict: Completely impractical for remote deployment.
Step 2: 10% Duty Cycle (Wake Every 1 Second)
The node wakes every 1 second, active for 100 ms + 5 ms overhead:
- Cycle period: 1000 ms
- Active time: 100 ms sensing/TX + 5 ms wake overhead
- Sleep time: 895 ms
Calculate average current:
\[ I_{avg} = \frac{(100 \text{ ms} \times 25 \text{ mA}) + (5 \text{ ms} \times 15 \text{ mA}) + (895 \text{ ms} \times 0.01 \text{ mA})}{1000 \text{ ms}} \]
\[ I_{avg} = \frac{2500 + 75 + 8.95}{1000} = \frac{2583.95}{1000} = 2.58 \text{ mA} \]
\[ \text{Battery Life} = \frac{2000 \text{ mAh}}{2.58 \text{ mA}} = 775 \text{ hours} = \mathbf{32.3 \text{ days}} \]
Verdict: Better, but still far from 1-year target.
Step 3: 1% Duty Cycle (Wake Every 10 Seconds)
The node wakes every 10 seconds:
- Cycle period: 10,000 ms
- Active time: 105 ms
- Sleep time: 9,895 ms
\[ I_{avg} = \frac{(100 \text{ ms} \times 25 \text{ mA}) + (5 \text{ ms} \times 15 \text{ mA}) + (9895 \text{ ms} \times 0.01 \text{ mA})}{10000 \text{ ms}} \]
\[ I_{avg} = \frac{2500 + 75 + 98.95}{10000} = 0.267 \text{ mA} = 267 \text{ µA} \]
\[ \text{Battery Life} = \frac{2000 \text{ mAh}}{0.267 \text{ mA}} = 7,491 \text{ hours} = \mathbf{312 \text{ days}} \]
Verdict: Close to 1 year but not quite meeting the requirement.
Step 4: 0.1% Duty Cycle (Wake Every 100 Seconds)
The node wakes every 100 seconds (~1.7 minutes):
- Cycle period: 100,000 ms
- Active time: 105 ms
- Sleep time: 99,895 ms
\[ I_{avg} = \frac{(100 \text{ ms} \times 25 \text{ mA}) + (5 \text{ ms} \times 15 \text{ mA}) + (99895 \text{ ms} \times 0.01 \text{ mA})}{100000 \text{ ms}} \]
\[ I_{avg} = \frac{2500 + 75 + 998.95}{100000} = 0.0357 \text{ mA} = 35.7 \text{ µA} \]
\[ \text{Battery Life} = \frac{2000 \text{ mAh}}{0.0357 \text{ mA}} = 56,022 \text{ hours} = \mathbf{6.4 \text{ years}} \]
Verdict: Exceeds 1-year requirement with significant margin!
9.4.3 Summary: Duty Cycle Comparison Table
| Duty Cycle | Sample Rate | Avg Current | Battery Life | Life vs Always-On | Meets 1-Year? |
|---|---|---|---|---|---|
| 100% | Continuous | 25 mA | 3.3 days | 1× (baseline) | ❌ No |
| 10% | 1/second | 2.58 mA | 32.3 days | 9.8× | ❌ No |
| 1% | 1/10 sec | 267 µA | 312 days | 94.5× | ❌ Close |
| 0.1% | 1/100 sec | 35.7 µA | 6.4 years | 708× | ✅ Yes |
9.4.4 Key Insights
1000× duty cycle reduction ≈ 700× battery life increase
Going from always-on (100%) to 0.1% duty cycle extends battery life from 3.3 days to 6.4 years—a factor of 708×.
Why not exactly 1000×? Three factors reduce the theoretical improvement:
- Sleep current is not zero: Even at 10 µA, sleep mode consumes energy over long periods
- Wake-up overhead: Each wake cycle costs ~5 ms at 15 mA regardless of active time
- Fixed active time: The 100 ms sensing/transmit time doesn’t scale down with duty cycle
Quantify the non-linearity between duty cycle reduction and battery life extension. At 0.1% duty cycle (100-second wake interval):
Active energy per cycle: \[E_{active} = 100 \text{ ms} \times 25 \text{ mA} = 2.5 \text{ mAs}\]
Wake overhead energy: \[E_{overhead} = 5 \text{ ms} \times 15 \text{ mA} = 0.075 \text{ mAs (3% of active energy)}\]
Sleep energy per cycle (99,895 ms): \[E_{sleep} = 99,895 \text{ ms} \times 0.01 \text{ mA} = 0.999 \text{ mAs (28% of total!)}\]
Total cycle energy: \(2.5 + 0.075 + 0.999 = 3.574\) mAs. Average current: \(3.574 / 100,000 = 35.7\) µA.
If we naively assumed zero sleep current and ignored overhead: \(2.5 / 100,000 = 25\) µA (43% underestimate). The overhead becomes dominant below 0.01% duty cycle, where wake cost exceeds active sensing energy.
Application-Specific Trade-offs:
| Application | Recommended Duty Cycle | Rationale |
|---|---|---|
| Fire detection | 0.1% (100s interval) | Temperature changes slowly; fires take minutes to spread |
| Intrusion detection | 1% (10s interval) | Need faster response to intruders |
| Structural monitoring | 0.01% (1000s interval) | Building stress changes over hours/days |
| Real-time tracking | 10% (1s interval) | Location updates needed frequently |
Design Recommendation for Fire Monitoring: Use 0.1% duty cycle with event-triggered wake-up. If temperature exceeds threshold, switch to 10% duty cycle to track fire progression rapidly.
9.4.5 Visual: Energy Budget Breakdown per Duty Cycle
The following diagram shows how the energy budget components shift as duty cycle decreases. At low duty cycles, sleep energy becomes the dominant consumer, but wake-up overhead becomes a larger fraction of the active energy.
At 0.1% duty cycle, sleep energy (999 µAs) accounts for 28% of total cycle energy despite the extremely low sleep current (10 µA). This is because the sleep period is 1000x longer than the active period. The wake-up overhead (75 µAs) is small here but becomes proportionally larger at even lower duty cycles.
9.4.6 Knowledge Check: Forest Fire Monitoring
A) The battery capacity decreases over time due to self-discharge
B) Sleep current, wake-up overhead, and fixed active time prevent linear scaling
C) The radio transmission becomes less efficient at lower duty cycles
D) The processor consumes more power when it wakes up less frequently
B) Sleep current, wake-up overhead, and fixed active time prevent linear scaling.
Three factors break the linear relationship: (1) sleep current is not zero – even 10 µA accumulates over long sleep periods, (2) each wake cycle has fixed overhead costs (5 ms at 15 mA) that do not shrink with duty cycle, and (3) the sensing/transmit time remains at 100 ms regardless of how often you sample. Together, these reduce the theoretical 1000x improvement to approximately 708x.
A) 5 minutes (300 seconds) – sample exactly at the detection deadline
B) 2.5 minutes (150 seconds) – sample at half the deadline for safety margin
C) 100 seconds – match the 0.1% duty cycle from the example
D) 10 seconds – fires spread too fast for any longer interval
B) 2.5 minutes (150 seconds) – sample at half the deadline for safety margin.
With a worst-case detection delay equal to one full wake interval (the event occurs just after the sensor sleeps), you need the interval to be less than 5 minutes. However, best practice is to use a safety margin of at least 50%, giving a maximum interval of 150 seconds. Option A is technically the absolute maximum but leaves zero margin. Option C (100 seconds from the example) is also acceptable and even more conservative. Option D is unnecessarily aggressive for fire detection, wasting battery life.
A) 2000 mAh – the full rated capacity
B) 1600 mAh – batteries lose 20% to self-discharge yearly
C) 2000 mAh – 80% of rated 2500 mAh due to voltage cutoff
D) 1600 mAh – 80% of 2000 mAh rated capacity due to voltage cutoff
D) 1600 mAh – 80% of 2000 mAh rated capacity due to voltage cutoff.
The problem states the battery is 2000 mAh with “usable ~80% due to voltage cutoff.” Alkaline batteries have a nominal capacity of 2000 mAh, but as they discharge, their voltage drops. The sensor circuitry has a minimum operating voltage (cutoff), below which the sensor cannot function. This typically means only about 80% of the rated capacity (1600 mAh) is usable. Note: The worked example uses the full 2000 mAh in its calculations for simplicity, which slightly overestimates battery life. In real deployments, always use the derated capacity.
9.5 Worked Example: Adaptive Duty Cycling for Agricultural Monitoring
A vineyard deploys 200 soil moisture sensors across 50 hectares. The sensors must operate for 2 years on a single AA battery (2400 mAh) while providing timely irrigation alerts. Unlike the fire monitoring example, this scenario introduces adaptive duty cycling – changing the sampling rate based on environmental conditions.
9.5.1 Given Parameters
| Parameter | Value | Notes |
|---|---|---|
| Battery capacity | 2400 mAh (usable: 2000 mAh) | 80% depth of discharge for alkaline |
| Active current | 18 mA | Capacitive soil sensor + radio TX |
| Sleep current | 8 µA | Deep sleep with soil comparator active |
| Active time per cycle | 150 ms | Sensor read (100 ms) + TX (50 ms) |
| Required lifetime | 2 years (17,520 hours) | Covers two full growing seasons |
9.5.2 Solution: Reverse Engineering the Duty Cycle
This example works backward from the lifetime target to determine the required duty cycle.
Step 1: Calculate maximum average current for 2-year lifetime:
\[I_{max} = \frac{2000 \text{ mAh}}{17520 \text{ hours}} = 0.114 \text{ mA} = 114 \text{ µA}\]
This is the current budget – the sensor cannot exceed 114 µA average if it must last 2 years.
Step 2: Calculate required duty cycle:
Using the standard duty cycle formula where \(D\) is the fraction of time spent active:
\[I_{avg} = D \times I_{active} + (1-D) \times I_{sleep}\]
\[114 \text{ µA} = D \times 18000 \text{ µA} + (1-D) \times 8 \text{ µA}\]
\[114 = 18000D + 8 - 8D\]
\[106 = 17992D\]
\[D = 0.0059 = 0.59\%\]
Step 3: Calculate wake interval for 0.59% duty cycle with 150 ms active time:
\[\text{Wake interval} = \frac{T_{active}}{D} = \frac{150 \text{ ms}}{0.0059} = 25.4 \text{ seconds}\]
Sampling every 25 seconds exactly meets the 2-year target. But can we do better?
Step 4: Design an adaptive strategy:
Soil moisture changes slowly during normal conditions but needs rapid monitoring during dry spells. This insight enables an adaptive duty cycle:
Step 5: Validate the adaptive strategy energy budget:
Assuming typical vineyard conditions (Mediterranean climate):
- Normal conditions (90% of time): Wake every 60 seconds (0.25% duty cycle) – 48 µA average
- Dry alert (9% of time): Wake every 10 seconds (1.5% duty cycle) – 270 µA average
- Critical alert (1% of time): Wake every 2 seconds (7.5% duty cycle) – 1,350 µA average
Weighted average current:
\[I_{weighted} = 0.90 \times 48 + 0.09 \times 270 + 0.01 \times 1350 = 43.2 + 24.3 + 13.5 = 81.0 \text{ µA}\]
\[\text{Battery Life} = \frac{2000 \text{ mAh}}{0.081 \text{ mA}} = 24,691 \text{ hours} = \mathbf{2.8 \text{ years}}\]
Result: The adaptive strategy achieves 2.8 years – 40% better than the 2-year requirement – while providing 6x faster response during dry conditions and 12.7x faster during critical events.
Adaptive duty cycling based on environmental conditions can provide both energy efficiency and application responsiveness. The key design principles are:
- Use hysteresis thresholds (30%/35%, 15%/20%) to prevent rapid oscillation between modes
- Keep high-rate periods short – even 10% of time at high duty cycle uses significant energy
- Budget for worst case – verify that even the maximum expected time in alert mode meets lifetime targets
9.5.3 Knowledge Check: Agricultural Monitoring
A) It eliminates the need to know the active and sleep currents
B) It directly tells you the maximum allowable current budget, constraining your design
C) It automatically selects the best MAC protocol for your application
D) It guarantees the sensor will last exactly the target lifetime
B) It directly tells you the maximum allowable current budget, constraining your design.
By dividing usable battery capacity by required lifetime, you get the maximum average current budget (114 µA in this case). This becomes a hard constraint for the entire design – any combination of duty cycle, active current, and sleep current must stay under this budget. It does not eliminate the need for other parameters (A), select protocols (C), or guarantee exact lifetime (D) since real-world factors like temperature and battery aging introduce uncertainty.
A) To save battery by using higher thresholds for returning to normal mode
B) To prevent rapid oscillation between modes when moisture is near a threshold value
C) To make the firmware implementation simpler
D) To comply with irrigation regulations that require specific measurement intervals
B) To prevent rapid oscillation between modes when moisture is near a threshold value.
Without hysteresis, a sensor reading that fluctuates around 30% moisture would constantly switch between Normal (60s) and DryAlert (10s) modes. Each transition might involve reconfiguring the radio, changing timer settings, and potentially sending a status update – all consuming energy. By requiring moisture to drop below 30% to enter DryAlert but rise above 35% to return to Normal, the sensor stays in one mode even with small reading variations. This is a standard control engineering technique called Schmitt trigger behavior.
9.6 Worked Example: Synchronization Overhead in Coordinated Sleep Schedules
A factory floor WSN uses S-MAC protocol with synchronized sleep schedules. Engineers notice battery life is 40% shorter than duty cycle calculations predict. This example demonstrates how to diagnose and fix the hidden synchronization overhead problem.
9.6.1 The Mystery: Predicted vs. Actual Battery Life
| Metric | Expected | Measured | Discrepancy |
|---|---|---|---|
| Average current | 0.21 mA | 0.35 mA | +67% |
| Battery life (3000 mAh) | 14,286 hours (1.6 yr) | 8,571 hours (0.98 yr) | -40% |
| Apparent duty cycle | 1.0% | ~1.7% | +70% |
9.6.2 Given Parameters
| Parameter | Value | Notes |
|---|---|---|
| Network size | 50 sensor nodes | Factory floor deployment |
| Sleep/wake cycle | 10 seconds | S-MAC synchronized schedule |
| Expected duty cycle | 1% (100 ms / 10 s) | Data sensing + transmission |
| Measured avg current | 0.35 mA | 67% higher than calculated 0.21 mA |
| S-MAC sync | SYNC packet every cycle | The hidden culprit |
| Clock drift | 30 ppm | Typical low-cost crystal oscillator |
9.6.4 Knowledge Check: Synchronization Overhead
A) The engineers used a default S-MAC configuration without tuning for their oscillator
B) The guard window must account for worst-case drift over the entire network lifetime
C) Low-cost oscillators have unpredictable drift that varies wildly cycle-to-cycle
D) The S-MAC specification requires a minimum 50 ms guard window regardless of drift
A) The engineers used a default S-MAC configuration without tuning for their oscillator.
The default S-MAC guard window is designed for worst-case oscillators (100+ ppm) and longer sync intervals. With 30 ppm drift and 10-second cycles, the actual drift is only 0.3 ms, but the guard window was 50 ms – a 166x overprovisioning. This is extremely common in practice: engineers use default protocol settings without performing the drift calculation specific to their hardware. The fix was straightforward: increase the sync interval to 60 seconds, where drift accumulates to 1.8 ms – still well within the 50 ms guard window but now syncing 6x less often.
A) When the network has more than 100 nodes
B) When synchronization overhead exceeds approximately 5% of the total energy budget
C) When the data rate is higher than 1 packet per second
D) When operating outdoors where temperature variations affect clock drift
B) When synchronization overhead exceeds approximately 5% of the total energy budget.
The 5% threshold is a practical guideline from the WSN literature. When sync overhead (guard time + SYNC packets) consumes more than 5% of total energy, asynchronous protocols like X-MAC (which use long preambles) or ContikiMAC (which use periodic wake-ups with fast channel checks) become more energy-efficient despite their own overhead costs. Network size (A) matters indirectly but is not the direct criterion. Higher data rates (C) actually favor synchronous protocols since they amortize sync costs over more data packets. Temperature (D) affects drift but does not automatically disqualify synchronous protocols.
9.7 Common Pitfalls in Duty Cycle Calculations
The Mistake: Developers configure nodes to wake every 10 seconds using their local oscillators, assuming all nodes stay synchronized after initial setup. Within days, packets are lost and the network fragments.
Why It Happens: Low-cost crystal oscillators drift 20-100 ppm (parts per million). At 50 ppm, clocks drift 4.32 seconds per day. After one week, nodes are 30+ seconds out of sync—their wake windows no longer overlap, so receivers are asleep when senders transmit.
The Fix: Implement periodic resynchronization based on your oscillator quality and wake window size: - Guard time formula: Guard_time = Clock_drift_ppm × Sync_interval × 2 - Example: 50 ppm drift, 60-second sync interval → Guard time = 50×10⁻⁶ × 60 × 2 = 6 ms minimum - Resync frequency: With 100 ms wake windows and 50 ppm drift, resync every 1000 seconds (16.7 min) to keep drift under 50 ms - Protocol choice: Use X-MAC or ContikiMAC (asynchronous) if synchronization overhead exceeds 5% of energy budget; use S-MAC (synchronous) only with accurate clocks (<30 ppm) and stable topologies
The Mistake: Engineers calculate that 0.1% duty cycle will provide 10-year battery life, but the network dies in 18 months. They assume energy scales linearly with duty cycle percentage.
Why It Happens: Every wake cycle has fixed overhead costs that don’t scale with duty cycle: oscillator stabilization (1-5 ms), radio PLL lock (0.5-2 ms), microcontroller boot (10-50 ms), and synchronization beacon transmission. At very low duty cycles, these fixed costs dominate.
The Fix: Calculate actual average current including wake overhead: - Formula: I_avg = (T_wake × I_wake + T_overhead × I_overhead + T_sleep × I_sleep) / T_cycle - Example breakdown for 0.1% duty cycle (wake every 100s): - Active sensing: 100 ms × 25 mA = 2.5 mAs - Wake overhead: 50 ms × 15 mA = 0.75 mAs (fixed per wake!) - Sleep: 99.85s × 10 µA = 0.999 mAs - Total per cycle: 4.25 mAs → 42.5 µA average (not 25 µA as naive calculation suggests) - Diminishing returns: Below 0.1% duty cycle, overhead typically exceeds 30% of active energy. Calculate your specific break-even point before targeting ultra-low duty cycles.
The Misconception: Many IoT practitioners assume that minimizing duty cycle (e.g., 0.01% vs 1%) always maximizes network lifetime.
Why It’s Wrong: Ultra-low duty cycles can reduce overall energy efficiency due to hidden overheads:
Energy breakdown for typical sensor node:
| Component | Power (mA) | Time (ms) | Energy (mJ @ 3.3V) |
|---|---|---|---|
| Sleep mode | 0.01 | - | 0.000033/s |
| Wake-up overhead | 15 | 50 | 2.475 |
| Sensing | 5 | 100 | 1.65 |
| Radio TX (10 bytes) | 30 | 5 | 0.495 |
| Total active cycle | - | 155 | 4.62 mJ |
1% Duty Cycle (36s active/hour, 100 wake cycles/hour):
- Wake overhead: 100 × 2.475 mJ = 247.5 mJ/hour
- Sensing/TX: 100 × (1.65 + 0.495) = 214.5 mJ/hour
- Sleep: 0.000033 mJ/s × 3564s = 0.12 mJ/hour
- Total: 462.1 mJ/hour
0.1% Duty Cycle (3.6s active/hour, 10 wake cycles/hour):
- Wake overhead: 10 × 2.475 mJ = 24.75 mJ/hour
- Sensing/TX: 10 × (1.65 + 0.495) = 21.45 mJ/hour
- Sleep: 0.000033 mJ/s × 3596.4s = 0.12 mJ/hour
- Total: 46.3 mJ/hour (10× improvement ✓)
0.01% Duty Cycle (0.36s active/hour, 1 wake cycle/hour) - THE TRAP:
- Wake overhead: 1 × 2.475 mJ = 2.475 mJ/hour
- Sensing/TX: 1 × (1.65 + 0.495) = 2.145 mJ/hour
- Sleep: 0.000033 mJ/s × 3599.6s = 0.12 mJ/hour
- Total: 4.74 mJ/hour
- But: Single reading may be insufficient for reliable event detection
- Reality: Need redundancy → 3 readings/hour = 14.2 mJ/hour (worse than 0.1% with better coverage!)
The Real Problem: At ultra-low duty cycles (<0.1%), wake-up overhead dominates, and you sacrifice detection reliability. Network may miss critical events, requiring denser deployment (more nodes = more total energy).
Quantified Impact - Agricultural Monitoring (100-node network, 1-year deployment):
| Strategy | Per-Node Energy | Detection Reliability | Nodes Needed | Total Network Energy |
|---|---|---|---|---|
| 1% duty cycle | 4.05 kWh/year | 99.9% | 100 | 405 kWh |
| 0.1% duty cycle | 405 Wh/year | 95% | 100 | 40.5 kWh |
| 0.01% duty cycle | 41.5 Wh/year | 60% (unacceptable) | 250 | 103.8 kWh (worst!) |
Optimal design: 0.1% duty cycle provides 90% energy savings vs 1% while maintaining reliability. Going lower requires 2.5× node density, negating energy benefits.
Best Practice: Choose duty cycle based on application requirements (detection probability, latency tolerance), not just minimal energy per node. Consider network-wide energy including deployment density.
9.8 Putting It All Together: Duty Cycle Design Decision Framework
The three worked examples and pitfall analyses lead to a systematic approach for duty cycle design. The following flowchart captures the decision process:
9.8.1 Quick Reference: Formulas Used in This Chapter
| Formula | Purpose | Example |
|---|---|---|
| \(I_{avg} = \frac{T_{active} \times I_{active} + T_{sleep} \times I_{sleep}}{T_{cycle}}\) | Basic average current | Forest fire Steps 1–4 |
| \(I_{max} = \frac{C_{battery}}{T_{lifetime}}\) | Current budget from lifetime target | Agricultural Step 1 |
| \(D = \frac{I_{max} - I_{sleep}}{I_{active} - I_{sleep}}\) | Required duty cycle from current budget | Agricultural Step 2 |
| \(T_{cycle} = \frac{T_{active}}{D}\) | Wake interval from duty cycle | Agricultural Step 3 |
| \(\text{Guard time} = \text{Drift}_{ppm} \times T_{sync} \times 2\) | Minimum guard time for clock drift | Sync example, Pitfall 1 |
| \(I_{weighted} = \sum p_i \times I_i\) | Weighted average for adaptive strategies | Agricultural Step 5 |
9.8.2 Final Knowledge Check
A) 6 readings per hour
B) 17 readings per hour
C) 34 readings per hour
D) 68 readings per hour
B) 17 readings per hour.
Step 1: Current budget: \(I_{max} = \frac{3000 \text{ mAh}}{5 \times 8760 \text{ h}} = 0.0685 \text{ mA} = 68.5\) µA
Step 2: Energy per reading: \(200 \text{ ms} \times 20 \text{ mA} = 4000\) µAs = 1.11 µAh
Step 3: Sleep current uses: \(5 \text{ µA} \times 1 \text{ h} = 5\) µAh per hour (constant background)
Step 4: Available for readings: \(68.5 - 5 = 63.5\) µAh per hour
Step 5: Readings per hour: \(\frac{63.5 \text{ µAh}}{1.11 \text{ µAh/reading}} \times \frac{1}{1 + \text{overhead factor}} \approx 17\) readings/hour (accounting for ~15% wake-up overhead that was not given explicitly but should always be assumed).
Note: Without overhead consideration, the raw answer would be \(63.5 / 1.11 \approx 57\) readings – this highlights why always including overhead in calculations is critical.
A) A water pipeline leak detector where leaks occur unpredictably and rarely
B) A traffic counter that measures vehicles at a highway toll booth with steady traffic
C) A temperature logger in a climate-controlled server room
D) A seismograph that records earthquake vibrations continuously
A) A water pipeline leak detector where leaks occur unpredictably and rarely.
Adaptive duty cycling excels when event rates vary significantly over time. A leak detector needs fast response when a leak occurs (high duty cycle) but can save energy during the vast majority of time when the pipe is intact (low duty cycle). Option B has steady, predictable traffic, so a fixed duty cycle is optimal. Option C monitors a controlled environment with minimal variation, making fixed sampling sufficient. Option D requires continuous monitoring during earthquakes, which are short events – but the seismograph must always be ready to capture the onset, favoring a different approach (event-triggered interrupt rather than duty cycling).
Scenario: A wildlife tracking WSN deployed in a forest has nodes dying at 8 months instead of the calculated 24-month lifetime. Battery voltage logs show rapid depletion in the final 2 weeks. You must diagnose the root cause.
Expected Configuration:
- Duty cycle: 1% (sample every 100 seconds)
- Active current: 25 mA for 100 ms
- Sleep current: 10 µA
- Calculated average: 0.267 mA → 24-month life on 5000 mAh battery
Actual Measurements (from field data logger): - Average current: 0.45 mA (not 0.267 mA — 68% higher!) - Wake-up frequency: Every 100 seconds (correct) - Active duration: 100 ms (correct) - Sleep current: 150 µA (not 10 µA — 15× higher!)
Diagnosis Steps:
Step 1: Identify the discrepancy Expected sleep: 10 µA × 99.9% duty = 10 µA contribution Actual sleep: 150 µA × 99.9% duty = 150 µA contribution Difference: 140 µA excess = 52% of total current
Step 2: Investigate sleep current sources
- Base MCU sleep: 10 µA (correct)
- GPS module: Should be powered off, but consuming 120 µA in “backup mode”
- Voltage regulator quiescent current: 15 µA (expected)
- External pull-up resistors: 5 µA (expected)
- Root cause: GPS module not fully powered down
Step 3: Calculate impact
- Original lifetime: 5000 mAh ÷ 0.267 mA = 18,727 hours = 780 days = 26 months
- Actual lifetime: 5000 mAh ÷ 0.45 mA = 11,111 hours = 463 days = 15.4 months
- Observed: 8 months (field data) vs 15.4 months (calculation)
- Additional 47% drain suggests temperature effects or self-discharge
Step 4: Root Cause Summary
- GPS module firmware bug: Backup mode instead of full power-down (120 µA excess)
- Cold temperatures: -10°C ambient reduces battery capacity by 20-30%
- Self-discharge: 2-3% per month at cold temps adds 5-8% annual loss
Step 5: Fix Implementation
// Original (incorrect)
gps.setSleepMode(GPS_BACKUP_MODE); // Still draws 120 µA
// Fixed (correct)
gps.powerOff(); // Hard power cut via MOSFET, <1 µA
digitalWrite(GPS_POWER_PIN, LOW);Result After Fix:
- Sleep current: 15 µA (vs 150 µA)
- Average current: 0.28 mA
- Expected lifetime: 17,857 hours = 24.5 months (close to design target)
- Field validation: 22 months (accounting for temperature effects)
Key Insight: Sleep current dominates at low duty cycles. Even a 140 µA excess (0.14 mA) reduces lifetime from 26 to 15 months when sleep is 99.9% of the time. Always measure actual sleep current with an ammeter before deployment.
| Factor | Fixed Duty Cycle | Adaptive Duty Cycle |
|---|---|---|
| Event Predictability | Periodic (temperature every 15 min) | Sporadic (intrusion detection) |
| Event Rate Variation | Low (<2× between conditions) | High (10-100× between normal/alert) |
| Energy Budget | Tight (must maximize lifetime) | Flexible (can trade energy for responsiveness) |
| Implementation Complexity | Simple (timer-based) | Complex (state machine + thresholds) |
| Firmware Size | <5 KB | 10-20 KB |
| False Alarm Tolerance | High (agricultural monitoring) | Low (security, safety-critical) |
| Typical Battery Life Gain | Baseline | 3-5× in low-event scenarios |
Decision Rules:
- Is event rate >10× higher during alerts than normal? → Adaptive
- Are false positives costly (evacuation, emergency response)? → Adaptive (high-frequency confirmation)
- Is firmware space <8 KB and code complexity critical? → Fixed
- Is energy the PRIMARY constraint (battery life >5 years required)? → Adaptive
- Are events regular and predictable? → Fixed
- Default for new deployments with unknown event patterns → Start Fixed, migrate to Adaptive after 3-month baseline
Implementation Checklist for Adaptive:
The Mistake: A soil sensor sleeps for 3600 seconds (1 hour) using the internal RC oscillator. The developer expects exactly 24 samples per day. After 30 days, data shows only 23.4 samples/day — the node is “losing” 14.4 minutes daily.
Why It Fails: Internal RC oscillators drift 2-5%: - Specified drift: 3% at 25°C - Sleep target: 3600 seconds - Actual sleep: 3600 × 1.03 = 3,708 seconds (108 seconds excess per cycle) - Daily loss: 24 cycles × 108s = 2,592 seconds = 43 minutes per day - After 30 days: 21.6 hours cumulative drift
The Fix: Use external 32.768 kHz crystal (10-20 ppm drift) or periodic resynchronization:
Option 1: External Crystal RTC
- Drift: 20 ppm = 0.002%
- Actual sleep: 3600 × 1.00002 = 3600.07 seconds
- Daily drift: 24 × 0.07s = 1.7 seconds (acceptable)
Option 2: GPS Time Sync (if GPS available)
unsigned long lastGPSSync = 0;
const unsigned long SYNC_INTERVAL = 86400000; // 24 hours
void loop() {
if (millis() - lastGPSSync > SYNC_INTERVAL) {
syncTimeWithGPS(); // Correct accumulated drift
lastGPSSync = millis();
}
// ... normal duty cycle ...
}Option 3: Calibrate RC Oscillator (advanced)
// Measure actual sleep duration against external reference
const float RC_CALIBRATION = 1.031; // Measured 3.1% fast
unsigned long adjustedSleep = 3600000 / RC_CALIBRATION; // 3,492 ms
esp_sleep_enable_timer_wakeup(adjustedSleep * 1000);Rule: For sleep periods >60 seconds, use external crystal RTC or GPS time sync. RC oscillators are acceptable only for sub-second timing where 3-5% error is tolerable.
9.9 Summary
This chapter provided detailed worked examples for duty cycle battery life analysis:
9.9.1 Key Takeaways
Forest fire monitoring: Step-by-step calculation showing how 0.1% duty cycle extends battery life from 3.3 days to 6.4 years – a 708x improvement, not the theoretical 1000x due to sleep current, wake overhead, and fixed active time.
Agricultural adaptive cycling: Reverse-engineering a duty cycle from a 2-year lifetime target (114 µA budget), then designing an adaptive strategy with hysteresis thresholds that achieves 2.8 years while providing 12.7x faster response during critical events.
Synchronization overhead diagnosis: Identifying that default S-MAC settings caused 67% higher current draw than expected. The fix – reducing sync frequency from 10s to 60s – improved battery life by 52% because the 50 ms guard window was 166x overprovisioned for the actual 0.3 ms drift.
Common pitfalls: (a) Clock drift fragments networks when sync windows miss each other; (b) wake-up overhead dominates at ultra-low duty cycles; (c) the lowest duty cycle is not always the most efficient when accounting for detection reliability and network-wide energy.
9.9.2 Design Rules of Thumb
| Rule | Guideline |
|---|---|
| Overhead threshold | If wake-up overhead > 30% of active energy, you have hit diminishing returns |
| Sync overhead | If sync energy > 5% of total, consider asynchronous MAC protocols |
| Detection margin | Set wake interval to at most 50% of maximum tolerable detection latency |
| Adaptive threshold | Use adaptive cycling when event rates vary by 10x or more across conditions |
| Battery derating | Always use 80% of rated capacity for alkaline, 90% for lithium batteries |
9.10 Knowledge Check
9.11 Concept Relationships
Prerequisites:
- Duty Cycle Fundamentals - Core concepts and formulas
Builds Upon:
- Battery life calculation with wake-up overhead
- EWMA reputation formulas for adaptive duty cycling
- ITU-R rain attenuation models for environmental effects
Enables:
- Accurate deployment planning with realistic battery estimates
- Adaptive duty cycling strategies for variable environments
- Diagnosing unexpected battery drain in production
Related Concepts:
- Clock drift impacts on synchronization energy
- Multi-tier adaptive duty cycles (normal/alert/critical modes)
- Cost-benefit analysis for mobile vs dedicated gateways
9.12 See Also
Hands-On Tools:
- Simulations Hub - Battery life calculators
- Python scripts in this chapter - Reusable for your deployments
Next Steps:
- CoRAD Drone Flight Planning - Recovery when nodes go offline
- Topology Management - Network-wide optimization
Real-World Context:
- Environmental Monitoring - Multi-year deployments
- Smart Agriculture - Adaptive sensing
- Energy Budget Calculation: A spreadsheet-style analysis summing the product of current draw and time duration for each operating state (active, receive, transmit, sleep) to compute average current and projected battery life
- Average Current: The weighted average of current consumption across all operating states: I_avg = (I_active × T_active + I_sleep × T_sleep) / T_total – the fundamental figure for battery life calculation
- CR2032 Coin Cell: A 3V, 240 mAh lithium manganese dioxide coin cell commonly used in IoT sensor nodes, providing up to 2-3 years at 10 µA average current, used as a benchmark in duty cycle calculations
- Radio Symbol Rate: The number of modulated symbols transmitted per second – with spread spectrum modulation, lower symbol rates provide more processing gain (longer range) at higher per-bit energy cost
- State Machine Energy Modeling: A technique for calculating energy consumption by mapping device states (IDLE, SENSING, TRANSMITTING, SLEEPING) to current draws and transition probabilities, enabling Monte Carlo or closed-form battery life prediction
- Event-Driven Duty Cycle: A duty cycling approach where the sensor remains in deep sleep until a hardware interrupt (PIR, accelerometer threshold) triggers wake-up, achieving near-zero average power for rare-event detection
- Burst Transmission: A power optimization strategy that buffers multiple sensor readings in memory during the sleep period and transmits them in a single radio burst, amortizing radio startup overhead across multiple data points
- Self-Discharge Rate: The current drawn by a battery even when no external load is connected (typically 0.5-2% per year for lithium cells), which becomes the dominant energy loss for sensors with very low duty cycles
9.14 What’s Next
| If you want to… | Read this |
|---|---|
| Understand the MAC protocols that implement duty cycling | Duty Cycle Fundamentals |
| Learn how duty cycling integrates with network topology | Duty Cycling and Topology Overview |
| Understand topology management and cluster head selection | Topology Management Techniques |
| Apply duty cycling in the context of wireless sensor networks | Wireless Sensor Networks |
| Review node behaviors that interact with duty cycling | Node Behavior Classification |