19  Case Studies and Best Practices

19.1 Learning Objectives

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

• Apply energy optimization techniques to real-world scenarios
• Analyze before/after optimization results
• Implement best practices for energy-aware design
• Avoid common pitfalls in low-power system design
• Create a systematic design process for battery-powered IoT

In 60 Seconds

Real-world case studies reveal that dramatic battery life improvements — from days to years — come from a systematic four-step process: profile current draw in every operating state, identify the dominant consumer, apply targeted optimization (duty cycling, sleep modes, or hardware power gating), then re-measure to confirm the saving.

For Beginners: Case Studies and Best Practices

This hands-on chapter lets you practice energy and power management for IoT devices. Think of it as learning to pack efficiently for a camping trip where every gram matters. Working through these exercises teaches you to measure power consumption, calculate battery life, and optimize your designs for maximum efficiency.

Sensor Squad: Real Stories of Energy Savings!

“Let me tell you about a farm sensor that only lasted two weeks on one battery,” said Bella the Battery. “The problem? It was sending data every 30 seconds over cellular, and the radio was the biggest energy hog. After optimization – sending every 15 minutes over LoRa instead – the same battery lasted over two YEARS!”

Sammy the Sensor explained the key changes: “They used three tricks. First, they switched from cellular to LoRa, which uses 100 times less energy per transmission. Second, they increased the sleep interval from 30 seconds to 15 minutes. Third, they added a solar panel for trickle charging. Each change multiplied the battery life!”

Max the Microcontroller shared the common pitfalls: “The biggest mistake is forgetting about the radio. People optimize the sensor and the processor but forget that transmitting one packet over Wi-Fi uses more energy than a THOUSAND temperature measurements. Always optimize the most expensive operation first!” Lila the LED added, “These case studies show that small changes can have HUGE impacts. A few smart decisions can turn a two-week device into a two-year device!”

Interactive: Energy Harvesting Analysis and Scenarios

19.2 Case Study: Optimizing Smart Agriculture Sensor

19.2.1 Initial Design (Battery Life: 2 weeks)

Hardware:

• ESP8266 (high power Wi-Fi)
• DHT22 sensor (slow, higher power)
• 2× AA alkaline batteries (3,000 mAh)
• Status LED (always on)

Firmware:

• Measure and transmit every 15 minutes
• Wi-Fi connection time: ~5 seconds
• No sleep mode (idle loop)

Measured Current:

• Active (Wi-Fi TX): 120 mA for 5 s
• Idle: 80 mA for 895 s

I_avg = (120×5 + 80×895) / 900 = 80.2 mA
Battery life = 3,000 mAh / 80.2 mA = 37 hours = 1.5 days

Actual measured: ~2 weeks (ESP8266 enters some sleep automatically)

19.2.2 Optimized Design (Battery Life: 2 years)

Hardware Changes:

• Switched to ESP32 (better sleep modes)
• SHT31 sensor (lower power, faster)
• 2× AA lithium primary (3,500 mAh, better discharge curve)
• Removed LED

Firmware Changes:

• Deep sleep between readings
• Wi-Fi connection optimized (static IP, channel, etc.)
• Transmission only on significant change
• Reduced transmission interval to 30 minutes

Measured Current:

• Deep sleep: 15 µA
• Wake + measure + transmit: 90 mA for 2 s

I_avg = (90×2 + 0.015×1,798) / 1,800 = 0.115 mA
Battery life = 3,500 mAh / 0.115 mA = 30,435 hours = 3.5 years

With efficiency factors: ~2.5 years

Interactive: Battery Life Calculator

Experiment with different sleep modes and duty cycles to see their impact on battery life:

viewof sleep_current = Inputs.range([1, 1000], {value: 15, step: 1, label: "Sleep current (µA)"})
viewof active_current = Inputs.range([10, 300], {value: 90, step: 5, label: "Active current (mA)"})
viewof active_time = Inputs.range([0.1, 30], {value: 2, step: 0.1, label: "Active time per cycle (s)"})
viewof cycle_time = Inputs.range([60, 7200], {value: 1800, step: 60, label: "Cycle period (s)"})
viewof battery_capacity = Inputs.range([500, 10000], {value: 3500, step: 100, label: "Battery capacity (mAh)"})

battery_calcs = {
  const sleep_time = cycle_time - active_time;
  const sleep_current_ma = sleep_current / 1000;
  const avg_current = (active_current * active_time + sleep_current_ma * sleep_time) / cycle_time;
  const life_hours = battery_capacity / avg_current;
  const life_days = life_hours / 24;
  const life_years = life_days / 365;
  const duty_cycle = (active_time / cycle_time) * 100;

  return {
    sleep_time,
    sleep_current_ma,
    avg_current,
    life_hours,
    life_days,
    life_years,
    duty_cycle
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<table style="width:100%; border-collapse:collapse;">
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Duty Cycle</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${battery_calcs.duty_cycle.toFixed(3)}%</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Average Current</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${battery_calcs.avg_current.toFixed(3)} mA</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Battery Life</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${battery_calcs.life_hours.toFixed(0)} hours = ${battery_calcs.life_days.toFixed(1)} days = ${battery_calcs.life_years.toFixed(2)} years</td></tr>
</table>
</div>`

Try adjusting the sleep current from 15 µA (deep sleep) to 100 µA (light sleep) to 2000 µA (idle mode) and observe the dramatic impact on battery life!

Putting Numbers to It

Let’s break down the optimized design calculation step-by-step:

Deep sleep power contribution:

• Sleep current: \(I_{\text{sleep}} = 15 \text{ µA} = 0.015 \text{ mA}\)
• Sleep duration per cycle: \(t_{\text{sleep}} = 1800 - 2 = 1798 \text{ s}\)
• Sleep contribution: \(I_{\text{sleep\_avg}} = \frac{0.015 \times 1798}{1800} = 0.01498 \text{ mA}\)

Active power contribution:

• Active current: \(I_{\text{active}} = 90 \text{ mA}\) (ESP32 + SHT31 + Wi-Fi TX)
• Active duration: \(t_{\text{active}} = 2 \text{ s}\) (wake + measure + transmit)
• Active contribution: \(I_{\text{active\_avg}} = \frac{90 \times 2}{1800} = 0.1 \text{ mA}\)

Total average current: \[I_{\text{avg}} = 0.01498 + 0.1 = 0.115 \text{ mA}\]

Battery life with 3500 mAh lithium primary: \[\text{Life} = \frac{3500 \text{ mAh}}{0.115 \text{ mA}} = 30,435 \text{ hours} = 1268 \text{ days} = 3.5 \text{ years}\]

Comparing to initial design (80.2 mA average): \[\text{Improvement} = \frac{80.2}{0.115} = 697\times \text{ better battery life}\]

This ~700× improvement came from: (1) deep sleep mode (5000× current reduction during 99.9% idle time), (2) faster sensor (50% less active time), and (3) transmission-on-change (50% fewer TX events).

19.2.3 Lessons Learned

Optimization	Impact
Deep sleep (vs idle)	5,000× reduction
Faster sensor	50% less active time
Removing LED	10 mA saved
Transmit on change	~50% fewer transmissions
Overall improvement	60× (2 weeks to 2 years)

19.3 Case Study: Livestock GPS Tracker – Digitanimal (Spain)

Digitanimal, a Spanish agtech company, produces GPS-enabled ear tags for cattle tracking across open rangeland. Their product evolution illustrates how iterative energy optimization transforms a failed prototype into a commercially viable product.

Generation 1 (2018) – Battery Life: 3 days

• GPS module: u-blox NEO-6M (always-on, continuous tracking)
• Radio: 2G cellular (GPRS), transmitting every 5 minutes
• Battery: 700 mAh LiPo
• Power draw: 85 mA average (GPS 40 mA + cellular 30 mA + MCU 15 mA)
• Result: Completely impractical. Farmers cannot replace ear tag batteries every 3 days across 500 cattle.

Generation 2 (2019) – Battery Life: 6 months

Optimization	Before	After	Impact
GPS duty cycle	Always-on	1 fix every 30 min, cold start	40 mA continuous -> 40 mA for 45s every 30 min = 1.0 mA avg
GPS hot start	Cold start (45s)	Store ephemeris, hot start (5s)	45s -> 5s active time = 0.11 mA avg GPS
Cellular protocol	GPRS (always connected)	NB-IoT (PSM mode)	30 mA continuous -> 120 mA for 2s every 30 min = 0.13 mA avg
MCU sleep	Light sleep (2 mA)	Deep sleep (8 uA)	15 mA -> 0.008 mA
Battery	700 mAh LiPo	1200 mAh LiPo + 80 mA solar cell	700 mAh -> effectively unlimited in summer

Average current dropped from 85 mA to 0.25 mA – a 340x improvement. Battery life without solar: 1200 mAh / 0.25 mA = 4,800 hours = 200 days. With solar supplement in summer months, devices run year-round.

Putting Numbers to It

Let’s quantify the GPS hot start optimization for Digitanimal’s livestock tracker:

Before (GPS cold start):

• GPS active time: 45 seconds per fix
• GPS current: \(I_{\text{GPS}} = 40 \text{ mA}\)
• Fix interval: 30 minutes = 1800 seconds
• GPS duty cycle: \(D_{\text{GPS}} = \frac{45}{1800} = 0.025\) (2.5%)
• GPS average current: \(I_{\text{GPS\_avg}} = 40 \times 0.025 = 1.0 \text{ mA}\)

After (GPS hot start with ephemeris storage):

• GPS active time: 5 seconds per fix (9× faster!)
• GPS duty cycle: \(D_{\text{GPS\_new}} = \frac{5}{1800} = 0.0028\) (0.28%)
• GPS average current: \(I_{\text{GPS\_avg\_new}} = 40 \times 0.0028 = 0.11 \text{ mA}\)

Energy savings: \[\text{Reduction} = 1.0 - 0.11 = 0.89 \text{ mA saved}\]

Impact on battery life (1200 mAh battery): - Before hot start: dominated by 1.0 mA GPS → ~50 days - After hot start: GPS contributes only 0.11 mA → enables 200+ day life

Implementation cost: Just 4 KB of flash memory to store ephemeris data (satellite orbital parameters), refreshed every 2 hours. This simple firmware change delivered 89% energy reduction in the most power-hungry component, extending battery life from 3 days to 3 weeks before any other optimizations. Combined with NB-IoT PSM and deep sleep MCU, final life reached 200 days.

19.4 Case Study: Industrial Vibration Sensor – SKF Enlight AI

SKF, the Swedish bearing manufacturer, deploys wireless vibration sensors on factory equipment for predictive maintenance. Their sensors must operate for 3-5 years on a single battery while sampling vibration at 25.6 kHz – an extreme challenge because high-frequency sampling is inherently power-hungry.

The Power Budget Challenge:

Vibration measurement: 25,600 samples/sec x 16 bits x 100ms burst = 40 mA for 0.1s
FFT computation on-device: 15 mA for 50ms (512-point FFT)
BLE transmission of spectrum: 12 mA for 200ms (2 KB compressed)
Deep sleep between measurements: 3 uA

Per-measurement energy: (40 x 0.1 + 15 x 0.05 + 12 x 0.2) = 7.15 mAs

Measurement interval selection – the critical tradeoff:

Interval	Avg Current	Battery Life (3600 mAh)	Failure Detection Lag
Every 1 min	119 uA	3.5 years	Catches fast-onset faults (minutes)
Every 10 min	12 uA	34 years (battery self-discharge limited to ~10 yr)	Misses rapid bearing failures
Every 1 hour	2.0 uA	Exceeds battery shelf life	Only catches gradual degradation

SKF chose every 10 minutes as the default, with adaptive scheduling: when baseline vibration levels increase by 20%, the sensor automatically switches to 1-minute intervals. This “slow-adapting with alert escalation” strategy borrows from biomimetic sensing principles – monitoring coarsely until something changes, then zooming in.

19.5 Best Practices

19.5.1 Design Phase

1. Define Energy Budget Early:

Set battery life requirement and work backwards:

Required I_avg = Battery Capacity / (Lifetime × Hours per day)

For 5 years on 2,400 mAh:

I_avg = 2,400 / (5 × 365 × 24) = 0.055 mA = 55 µA

This target guides all design decisions.

2. Choose Components for Power:

Select components with sleep modes compatible with your budget. A 100 µA sleep current component consumes your entire budget in the above example.

3. Plan for Measurement:

Include test points, current measurement breakout, and profiling GPIOs in PCB design.

4. Oversize Battery:

Add 50-100% margin for:

• Degradation over time
• Temperature effects
• Underestimated consumption

19.5.2 Implementation Phase

1. Measure Early and Often:

Don’t wait until final prototype. Measure breadboard consumption to validate assumptions.

2. Profile All States:

Measure deep sleep, light sleep, idle, and active states separately. One misconfigured peripheral can ruin battery life.

3. Test Wake-Up Time:

Ensure wake-up time + operation time fits budget. Fast wake is critical for short duty cycles.

4. Verify Actual Sleep:

Check that device actually enters deep sleep. Misconfiguration can leave peripherals powered (1,000× consumption difference).

19.5.3 Testing and Validation

1. Long-Term Current Monitoring:

Capture current profile over hours/days to find:

• Unexpected wake-ups
• Slow leaks
• Periodic background tasks

2. Temperature Testing:

Battery capacity and device current vary with temperature. Test at operational extremes (0°C, 50°C).

3. End-of-Life Testing:

Test behavior at low battery voltage. Some devices malfunction or increase current when battery depletes.

4. Production Validation:

Measure sample of production units. Manufacturing variations (solder bridges, wrong components) can increase current.

19.5.4 Common Pitfalls to Avoid

Critical Pitfalls That Destroy Battery Life

1. Forgetting Pull-ups/Pull-downs:

10 kΩ pull-up on unused GPIO at 3.3V = 330 µA continuous (destroys battery life).

2. Leaving Debug Interfaces Active:

UART, JTAG, USB-serial chips can consume mA when not disabled.

3. Floating Inputs:

Unconnected MCU pins can oscillate, consuming excessive current. Configure as outputs or enable pull-ups/downs.

4. Incorrect Sleep API Usage:

Using wrong sleep function or forgetting to configure wake source prevents deep sleep.

5. Ignoring LDO Quiescent Current:

High quiescent current regulator (100 µA) wastes power even in sleep.

6. Over-Optimistic Battery Ratings:

Battery capacity ratings often assume ideal conditions (20°C, low discharge rate). Real capacity may be 60-80% of rating.

19.6 Comprehensive Review Quiz

Test your understanding of energy-aware design principles:

## Conclusion

Energy awareness is not optional in IoT design—it’s fundamental. The difference between a device lasting weeks versus years depends entirely on careful attention to energy consumption at every level:

• Component selection
• Circuit design
• Firmware implementation
• Communication strategies

Modern IoT platforms provide powerful tools for ultra-low-power operation: microcontrollers with sub-microamp sleep modes, energy-efficient wireless protocols, and sophisticated power management ICs. However, these capabilities only deliver results when systematically applied.

Energy harvesting extends these principles further, enabling battery-free operation for applications with access to solar, thermal, kinetic, or RF energy sources. Properly designed energy harvesting systems can operate perpetually, eliminating maintenance costs and environmental impact of battery disposal.

The investment in energy-aware design pays immediate dividends: longer battery life reduces maintenance costs, enables new deployment scenarios, improves user experience, and demonstrates engineering excellence. As IoT scales to billions of devices, energy efficiency becomes not just a technical requirement but an environmental and economic imperative.

19.7 Key Concepts Summary

Power States:

• Active: Full functionality, maximum power
• Idle: Processing on demand, reduced power
• Light Sleep: Core active, peripherals off
• Deep Sleep: Minimal power, fast wake
• Hibernation: Almost no power, slow wake

Power Reduction Techniques:

• Voltage scaling: Reduce operating voltage
• Frequency scaling: Lower clock frequency
• Peripheral shutdown: Disable unused modules
• Sleep modes: Minimize always-on components
• Duty cycling: Intermittent operation

Communication Efficiency:

• Minimize transmission frequency and power
• Use low-power protocols: BLE, Zigbee, LoRa
• Batch messages: Amortize overhead
• Compression: Reduce data size
• Local processing: Reduce cloud transmission

Energy Harvesting:

• Solar: Photovoltaic panels
• Thermal: Seebeck effect, temperature gradient
• Kinetic: Piezoelectric, electromagnetic
• RF: Wireless power, ambient RF energy

Design Methodology:

• Profile actual power consumption
• Identify high-consumption components
• Optimize for longest sleep periods
• Measure battery life in practice
• Plan for battery degradation

19.8 See Also

Related Topics:

• Hardware and Software Optimization: Complementary techniques for code efficiency
• Sensors and Actuation: Understanding sensor power profiles
• Networking Protocols: Comparing protocol energy consumption

Further Reading:

• Edge Computing: Local processing reduces transmission energy
• MQTT and CoAP Protocols: Lightweight protocols for low-power operation
• IoT Use Cases: Real-world energy optimization examples

Worked Example: Solar Panel Sizing for Year-Round Operation

A remote weather station needs solar + battery backup for 7 days of cloudy weather. Average power: 5 mA @ 3.7V.

Step 1 - Calculate daily energy consumption:

Power = 5 mA × 3.7 V = 18.5 mW = 0.0185 W
Daily energy = 0.0185 W × 24 hours = 0.444 Wh/day

Step 2 - Size battery for 7-day backup:

Backup energy = 0.444 Wh × 7 days = 3.1 Wh
With 80% depth of discharge (LiPo safe limit):
Required capacity = 3.1 / 0.8 = 3.88 Wh = 1,050 mAh @ 3.7V
→ Select: 1,200 mAh LiPo (standard size)

Step 3 - Calculate solar panel requirements: Worst-case location: 45° latitude, winter solstice - Peak sun hours: 3.5 hours/day (NREL data for Dec) - De-rating factors: - Panel efficiency degradation: 0.9 (10% loss over 5 years) - MPPT efficiency: 0.85 - Dust/snow/angle: 0.7 - Total efficiency: 0.9 × 0.85 × 0.7 = 0.54

Required panel output = 0.444 Wh/day / (3.5 hours × 0.54 efficiency)
                      = 0.444 / 1.89 = 0.235 W minimum

Add 50% margin for weather variance:
Panel size = 0.235 × 1.5 = 0.35 W
→ Select: 0.5 W / 5V panel (standard module)

Step 4 - Validate with summer surplus: Summer peak sun hours: 9 hours/day

Summer harvest = 0.5 W × 9 hours × 0.54 = 2.43 Wh/day
Consumption = 0.444 Wh/day
Surplus = 2.43 - 0.444 = 2.0 Wh/day (recharges battery in 2 days after winter drain)

Result: 0.5 W panel + 1,200 mAh battery = year-round operation. This sizing prevented oversizing to a 2 W panel ($40 vs $12).

Interactive: Solar Panel Sizing Calculator

Design your own solar-powered IoT sensor system:

viewof device_current = Inputs.range([0.1, 50], {value: 5, step: 0.1, label: "Average device current (mA)"})
viewof device_voltage = Inputs.range([1.8, 12], {value: 3.7, step: 0.1, label: "Operating voltage (V)"})
viewof backup_days = Inputs.range([1, 30], {value: 7, step: 1, label: "Cloudy weather backup (days)"})
viewof depth_of_discharge = Inputs.range([0.5, 0.9], {value: 0.8, step: 0.05, label: "Battery depth of discharge"})
viewof peak_sun_hours_winter = Inputs.range([1, 10], {value: 3.5, step: 0.5, label: "Winter peak sun hours/day"})
viewof system_efficiency = Inputs.range([0.3, 0.9], {value: 0.54, step: 0.05, label: "Overall system efficiency"})

solar_calcs = {
  const daily_power_w = (device_current / 1000) * device_voltage;
  const daily_energy_wh = daily_power_w * 24;
  const backup_energy_wh = daily_energy_wh * backup_days;
  const battery_capacity_wh = backup_energy_wh / depth_of_discharge;
  const battery_capacity_mah = (battery_capacity_wh / device_voltage) * 1000;
  const required_panel_w = daily_energy_wh / (peak_sun_hours_winter * system_efficiency);
  const panel_w_with_margin = required_panel_w * 1.5; // 50% safety margin

  return {
    daily_power_w,
    daily_energy_wh,
    backup_energy_wh,
    battery_capacity_wh,
    battery_capacity_mah,
    required_panel_w,
    panel_w_with_margin
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem;">
<h4 style="margin-top:0; color: #16A085;">System Design Results</h4>
<table style="width:100%; border-collapse:collapse; margin-top: 0.5rem;">
<tr style="background: #e8f4f1;"><td colspan="2" style="padding:8px; border:1px solid #ddd; font-weight:bold;">Energy Requirements</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Daily energy consumption</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${solar_calcs.daily_energy_wh.toFixed(3)} Wh/day</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>${backup_days}-day backup energy</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${solar_calcs.backup_energy_wh.toFixed(2)} Wh</td></tr>
<tr style="background: #e8f4f1;"><td colspan="2" style="padding:8px; border:1px solid #ddd; font-weight:bold;">Battery Sizing</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Required battery capacity</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${solar_calcs.battery_capacity_wh.toFixed(2)} Wh = ${solar_calcs.battery_capacity_mah.toFixed(0)} mAh @ ${device_voltage}V</td></tr>
<tr style="background: #e8f4f1;"><td colspan="2" style="padding:8px; border:1px solid #ddd; font-weight:bold;">Solar Panel Sizing</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Minimum panel power</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${solar_calcs.required_panel_w.toFixed(3)} W</td></tr>
<tr><td style="padding:8px; border:1px solid #ddd;"><strong>Recommended (with 50% margin)</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">${solar_calcs.panel_w_with_margin.toFixed(2)} W</td></tr>
</table>
</div>`

Experiment with different backup durations and winter sun hours to understand the tradeoffs between battery size and solar panel capacity.

Decision Framework: Choosing Sleep Modes for Different Duty Cycle Applications

Application	Active Time	Sleep Time	Active Power	Optimal Sleep Mode	Avg Current	Battery Life (2,000 mAh)
Environmental sensor (15 min)	2 sec TX	898 sec sleep	80 mA	Deep sleep (10 µA)	18.7 µA	12 years
Motion detector (always ready)	50 ms burst	950 ms idle	30 mA	Light sleep (100 µA)	96.5 µA	2.4 years
GPS tracker (1 min)	30 sec fix + TX	30 sec sleep	100 mA	Light sleep	50.05 mA	40 hours
Video doorbell (on-demand)	60 sec stream	23h 59m idle	500 mA	Deep sleep	8.35 µA	27 years
Smart thermostat (5 min)	100 ms UI check	299.9 sec sleep	50 mA	Deep sleep	3.35 µA	68 years (limited by battery shelf life)

Selection criteria:

1. Wake latency tolerance → If <10 ms required, use light sleep; if >500 ms OK, use deep sleep
2. Wake frequency → If >1/second, light sleep avoids constant wake overhead; if <1/minute, deep sleep dominates
3. Active duration → If <100 ms, wake overhead matters; if >1 second, sleep mode dominates

Trade-off equation:

I_avg = (I_active × T_active + I_sleep × T_sleep) / (T_active + T_sleep)

For 1% duty cycle: - Light sleep (100 µA): I_avg = (30 mA × 0.01) + (0.1 mA × 0.99) = 0.399 mA - Deep sleep (10 µA): I_avg = (30 mA × 0.01) + (0.01 mA × 0.99) = 0.310 mA - Savings: 22% (deep sleep wins unless wake latency is critical)

When light sleep wins: If waking >10 times/second, deep sleep overhead (100-300 µs each wake) can cost more energy than light sleep’s higher idle current.

Interactive: Sleep Mode Comparison Calculator

Compare deep sleep vs light sleep for your application:

viewof app_active_time = Inputs.range([10, 10000], {value: 2000, step: 10, label: "Active time per cycle (ms)"})
viewof app_sleep_time = Inputs.range([100, 300000], {value: 898000, step: 1000, label: "Sleep time per cycle (ms)"})
viewof app_active_current = Inputs.range([10, 500], {value: 80, step: 5, label: "Active current (mA)"})

sleep_comparison = {
  const cycle_time_s = (app_active_time + app_sleep_time) / 1000;
  const active_time_s = app_active_time / 1000;
  const sleep_time_s = app_sleep_time / 1000;
  const duty_cycle = (active_time_s / cycle_time_s) * 100;

  // Deep sleep mode (10 µA)
  const deep_sleep_current = 0.01; // mA
  const deep_avg = (app_active_current * active_time_s + deep_sleep_current * sleep_time_s) / cycle_time_s;

  // Light sleep mode (100 µA)
  const light_sleep_current = 0.1; // mA
  const light_avg = (app_active_current * active_time_s + light_sleep_current * sleep_time_s) / cycle_time_s;

  // Idle mode (2 mA)
  const idle_current = 2; // mA
  const idle_avg = (app_active_current * active_time_s + idle_current * sleep_time_s) / cycle_time_s;

  // Battery life with 2000 mAh
  const battery_capacity = 2000;
  const deep_life_years = (battery_capacity / deep_avg) / 24 / 365;
  const light_life_years = (battery_capacity / light_avg) / 24 / 365;
  const idle_life_years = (battery_capacity / idle_avg) / 24 / 365;

  return {
    duty_cycle,
    deep_avg,
    light_avg,
    idle_avg,
    deep_life_years,
    light_life_years,
    idle_life_years
  };
}

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #E67E22; margin-top: 0.5rem;">
<h4 style="margin-top:0; color: #E67E22;">Sleep Mode Comparison (2000 mAh battery)</h4>
<p><strong>Duty Cycle:</strong> ${sleep_comparison.duty_cycle.toFixed(3)}%</p>
<table style="width:100%; border-collapse:collapse; margin-top: 0.5rem;">
<tr style="background: #2C3E50; color: white;">
    <th style="padding:8px; border:1px solid #ddd; text-align:left;">Sleep Mode</th>
    <th style="padding:8px; border:1px solid #ddd; text-align:left;">Sleep Current</th>
    <th style="padding:8px; border:1px solid #ddd; text-align:left;">Avg Current</th>
    <th style="padding:8px; border:1px solid #ddd; text-align:left;">Battery Life</th>
</tr>
<tr style="background: #d4edda;">
    <td style="padding:8px; border:1px solid #ddd;"><strong>Deep Sleep</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">10 µA</td>
    <td style="padding:8px; border:1px solid #ddd;">${sleep_comparison.deep_avg.toFixed(3)} mA</td>
    <td style="padding:8px; border:1px solid #ddd;"><strong>${sleep_comparison.deep_life_years.toFixed(2)} years</strong></td>
</tr>
<tr style="background: #fff3cd;">
    <td style="padding:8px; border:1px solid #ddd;"><strong>Light Sleep</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">100 µA</td>
    <td style="padding:8px; border:1px solid #ddd;">${sleep_comparison.light_avg.toFixed(3)} mA</td>
    <td style="padding:8px; border:1px solid #ddd;">${sleep_comparison.light_life_years.toFixed(2)} years</td>
</tr>
<tr style="background: #f8d7da;">
    <td style="padding:8px; border:1px solid #ddd;"><strong>Idle (No Sleep)</strong></td>
    <td style="padding:8px; border:1px solid #ddd;">2 mA</td>
    <td style="padding:8px; border:1px solid #ddd;">${sleep_comparison.idle_avg.toFixed(3)} mA</td>
    <td style="padding:8px; border:1px solid #ddd;">${sleep_comparison.idle_life_years.toFixed(2)} years</td>
</tr>
</table>
</div>`

Adjust the duty cycle to see when deep sleep vs light sleep makes the most difference. For very low duty cycles (<1%), deep sleep dominates battery life.

Common Mistake: Trusting Datasheet “Typical” Current Instead of Measuring Actual

What they do wrong: Engineers calculate battery life using datasheet “typical” values (e.g., “Deep sleep: 10 µA typ”) without measuring their actual hardware.

Why it fails: Real sleep current includes: - Voltage regulator quiescent current (often 50-100 µA) - Pull-up/pull-down resistors (10 kΩ at 3.3V = 330 µA!) - LEDs with high-value resistors (1 kΩ = 3.3 mA) - Peripheral chips not in shutdown mode - PCB leakage current

Example: ESP32 datasheet shows 10 µA deep sleep. Actual measured board current: 180 µA (18× higher!)

Breakdown of 170 µA mystery current:

• Voltage regulator (LM1117): 60 µA quiescent
• USB-UART bridge (CH340): 70 µA (not powered down!)
• I2C pull-ups (2× 10kΩ on 3.3V): 2 × 330 µA = 660 µA (oops - should be 47kΩ!)
• Actual ESP32 sleep: 10 µA

Redesign with proper components: - Replace LM1117 with MCP1700 (2 µA quiescent): saves 58 µA - Add MOSFET to cut power to CH340: saves 70 µA - Change pull-ups to 47 kΩ: saves 590 µA - New total: 12 µA (matches datasheet!)

Battery life impact:

• Original (180 µA): 2,000 mAh / 0.18 mA = 11,111 hours = 463 days
• Optimized (12 µA): 2,000 mAh / 0.012 mA = 166,667 hours = 19 years!

Correct approach: ALWAYS measure actual board current with ammeter/power analyzer before finalizing battery life calculations. Use worst-case datasheet values (max, not typical) for conservative estimates.

Real example: A company shipped 5,000 LoRa sensors expecting 5-year battery life based on ESP32 datasheet 10 µA sleep current. Actual field life: 8 months. Root cause: 150 µA regulator quiescent + 100 µA from UART bridge they forgot to disable. Recall cost: $275,000. Lesson: Measure don’t assume.

19.9 Concept Relationships

These case studies demonstrate the interplay of multiple energy management concepts:

Design Methodology:

• Requirements Engineering: Battery life targets drive component selection and architecture decisions
• Pareto Optimization: Trading off features (transmission frequency) against battery life
• Failure Mode Analysis: Identifying energy-draining edge cases (pull-up resistors, regulator quiescent current)

Power Management Techniques:

• Duty Cycling: All case studies achieve multi-year life through extreme duty cycles (<1%)
• Sleep Mode Selection: Deep sleep vs light sleep tradeoffs based on wake latency requirements
• Peripheral Power Gating: Digitanimal’s MOSFET-switched sensors demonstrate hardware-level power control

System Architecture:

• Protocol Selection: Wi-Fi vs LoRa vs NB-IoT energy cost comparisons
• Local vs Cloud Processing: SKF’s on-device FFT processing reduces transmission energy
• Adaptive Behavior: Temperature-based sampling interval adjustment in smart agriculture

Understanding these relationships helps engineers avoid repeating common mistakes and apply successful patterns to new designs.

19.10 See Also

Related Energy Topics:

• Energy Aware Considerations - Foundational power vs energy concepts and battery chemistry
• Energy Measurement and Profiling - Tools and techniques for validating battery life predictions
• Energy Harvesting Design - Solar panel sizing and MPPT implementation

Hardware and Optimization:

• Hardware and Software Optimisation - Compiler optimization and code efficiency
• Context-Aware Energy Management - ACE system and adaptive duty cycling

Communication Protocols:

• LoRaWAN Overview - Class A/B/C power modes and duty cycle regulations
• NB-IoT - PSM and eDRX modes for cellular IoT energy efficiency
• Bluetooth BLE - Advertising intervals and connection parameters

Deployment Best Practices:

• Environmental Considerations - Temperature effects, weatherproofing, maintenance access
• Testing and Validation - Field trials and reliability engineering

Matching Quiz: Match Case Studies to Key Lessons

Ordering Quiz: Order the Power Optimization Workflow

Label the Diagram

19.11 What’s Next

If you want to…	Read this
Understand context-aware adaptive power management	Context-Aware Energy Management
Review the full energy-aware design framework	Energy-Aware Considerations
Learn measurement tools and techniques	Energy-Aware Measurement
Explore energy sources and harvesting	Energy Sources Overview
Practice with low-power strategies	Low-Power Strategies

💻 Code Challenge

Order the Steps

Match the Concepts