48  Edge Power & Gateways

In 60 Seconds

Battery life is the primary constraint for most IoT edge devices. Through duty cycling – alternating between short active/transmit periods and long deep sleep periods – a device’s battery life can be extended from months to years (4-5x improvement). Gateways bridge non-IP sensors to the internet by providing protocol translation, store-and-forward buffering during outages, and security functions.

48.1 Learning Objectives

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

  • Calculate Power Budgets: Compute battery life for IoT devices based on duty cycling and transmission patterns
  • Design Duty Cycling Strategies: Configure active, transmit, and sleep cycles and evaluate their impact on battery longevity
  • Explain Gateway Functions: Describe how gateways enable non-IP devices to participate in IoT networks through protocol translation
  • Implement Store-and-Forward: Design and assess reliable data pipelines that survive network outages

Edge data acquisition is about collecting and pre-processing sensor data right where the devices are, before sending it to the cloud. Think of a smart mailroom that sorts and summarizes incoming letters instead of forwarding every piece of junk mail to the CEO. This local filtering saves bandwidth, reduces costs, and speeds up responses.

48.2 Prerequisites

Before diving into this chapter, you should be familiar with:

48.3 Power Management and Duty Cycling

Time: ~15 min | Difficulty: Advanced | Reference: P10.C08.U04

Key Concepts

  • Energy harvesting: Generating power for edge devices from ambient sources (solar, vibration, thermal gradients, RF) to enable autonomous operation in locations without permanent power infrastructure.
  • Duty cycling: Periodically powering down sensor hardware and radio between measurements to dramatically reduce average current consumption, extending battery life from days to years.
  • Gateway protocol translation: Converting between device-side protocols (BLE, Zigbee, Modbus) and cloud-side protocols (MQTT, HTTPS, AMQP) at the gateway, enabling heterogeneous device ecosystems to integrate with standard cloud platforms.
  • Store-and-forward: A gateway capability that buffers sensor data locally during connectivity outages and transmits it to the cloud when connectivity is restored, preventing data loss during network failures.
  • Power budget analysis: A calculation determining the average power consumption of an edge device across all operating modes (active sensing, radio transmission, sleep) to estimate battery life or harvesting requirements.
  • Watchdog timer: A hardware timer that resets the microcontroller if not periodically refreshed by the application, providing automatic recovery from software hangs in unattended edge deployments.

Battery life is the primary constraint for most edge IoT devices. Understanding power consumption patterns is essential for designing practical systems.

48.3.1 Power States

Most IoT microcontrollers support multiple power states:

State ESP32 Current Activity
Active 80-240 mA CPU + Wi-Fi active
Light Sleep 0.8 mA CPU paused, Wi-Fi off
Deep Sleep 10 uA Only RTC active
Hibernation 2.5 uA Only wake timer

48.3.2 Duty Cycling Formula

Average current consumption with duty cycling:

\[I_{avg} = \frac{t_{active} \times I_{active} + t_{tx} \times I_{tx} + t_{sleep} \times I_{sleep}}{t_{total}}\]

Where:

  • \(t_{active}\) = time in active mode (sensing, processing)
  • \(t_{tx}\) = time transmitting
  • \(t_{sleep}\) = time in sleep mode
  • \(I_{active}\), \(I_{tx}\), \(I_{sleep}\) = current draw in each mode

Battery life calculation:

\[Life_{hours} = \frac{Battery_{mAh}}{I_{avg}}\]

48.3.3 Example Calculation

Scenario: ESP32 with 2500 mAh battery

Mode Duration (per hour) Current Energy Contribution
Active 30 seconds 25 mA 0.208 mAh
Transmit 10 seconds 120 mA 0.333 mAh
Deep Sleep 3560 seconds 0.01 mA 0.010 mAh

Average current: (30 x 25 + 10 x 120 + 3560 x 0.01) / 3600 = 0.55 mA

Battery life: 2500 mAh / 0.55 mA = 4,545 hours = 189 days

48.3.4 Optimized Design

Reduce active to 5 seconds, transmit to 2 seconds:

Mode Duration (per hour) Current Energy Contribution
Active 5 seconds 25 mA 0.035 mAh
Transmit 2 seconds 120 mA 0.067 mAh
Deep Sleep 3593 seconds 0.01 mA 0.010 mAh

Average current: (5 x 25 + 2 x 120 + 3593 x 0.01) / 3600 = 0.112 mA

Battery life: 2500 mAh / 0.112 mA = 22,321 hours = 2.5 years

Improvement factor: 4.9x (from ~6 months to 2.5+ years)

48.3.5 Interactive Battery Life Calculator

Use this calculator to explore how duty cycling parameters affect battery life. Adjust active time, transmit time, current draw, and battery capacity to see real-time results.

Why does transmission dominate power budget?

For an ESP32 with LoRa module transmitting 50 bytes: - Deep sleep: 10 µA × 3600s = 0.01 mAh/hour - Active (sensing): 80 mA × 5s = 0.111 mAh per activation - LoRa TX (SF7, +14dBm): 120 mA × 2s = 0.067 mAh per transmission

Energy per transmission: \(E_{tx} = 120 \text{ mA} \times 2 \text{ s} = 0.067 \text{ mAh}\)

Energy per sensing: \(E_{sense} = 80 \text{ mA} \times 5 \text{ s} = 0.111 \text{ mAh}\)

Total active energy: \(0.067 + 0.111 = 0.178 \text{ mAh}\) per cycle

If transmitting every 5 minutes (12×/hour):

  • Active/TX energy: \(0.178 \times 12 = 2.14 \text{ mAh/hour}\)
  • Sleep energy: \(0.01 \text{ mAh/hour}\)
  • TX represents \(\frac{0.067 \times 12}{2.14} = 38\%\) of total energy

Batching strategy: Transmit 6 readings once per 30 min (2×/hour) instead of 12×/hour: - Active/TX energy: \(0.178 \times 2 = 0.36 \text{ mAh/hour}\) - Battery life improves by \(\frac{2.14}{0.36} = 6.0\times\)

Radio dominates because TX power (120 mA) is 12× higher than active CPU (10 mA baseline), even though TX duration is shorter.

48.4 Knowledge Check: Battery Life

48.5 Gateway Functions for Non-IP Devices

Time: ~10 min | Difficulty: Intermediate | Reference: P10.C08.U05

Gateways serve as critical bridges between non-IP devices and the internet. Key functions include:

48.5.1 Protocol Translation

  • Convert sensor-specific protocols (Modbus, BACnet, Zigbee) to IP protocols
  • Translate between MQTT, CoAP, and HTTP as needed
  • Handle message format conversion (binary to JSON)

48.5.2 Data Buffering

  • Store data during network outages
  • Batch multiple sensor readings for efficient transmission
  • Implement store-and-forward for intermittent connectivity

48.5.3 Security Functions

  • Encrypt data before transmission to cloud
  • Authenticate devices and manage credentials
  • Filter and validate incoming commands
Diagram showing edge gateway functions including protocol translation from non-IP protocols like Modbus, BACnet, and Zigbee to IP-based cloud protocols, with data buffering and security layers
Figure 48.1: Edge Gateway Protocol Translation and Cloud Connectivity

48.6 Handling Missing Data

Time: ~8 min | Difficulty: Intermediate | Reference: P10.C08.U05b

Common Pitfall: Missing Data Deletion

The mistake: Deleting rows with missing sensor values instead of using appropriate imputation or flagging strategies, losing valuable contextual information.

Symptoms:

  • Dataset shrinks dramatically after preprocessing (e.g., 1M rows becomes 200K)
  • Model accuracy drops when deployed despite good validation scores
  • Time gaps in data break time-series analysis (autocorrelation, windowing)
  • Critical events during sensor outages are completely missed

Why it happens: Beginners apply pandas dropna() liberally. In IoT, sensors fail intermittently due to battery depletion, network issues, or environmental factors. Deleting these rows removes entire time windows, including valid data from other sensors.

The fix: Use context-appropriate imputation strategies:

# For slow-changing values (temperature): forward-fill
df['temp'] = df['temp'].ffill(limit=60)  # Max 60 missing samples

# For periodic values: interpolation
df['humidity'] = df['humidity'].interpolate(method='time')

# For event-driven sensors: mark as "no event" vs "missing"
df['motion_event'] = df['motion'].fillna(0)  # No motion detected
df['motion_missing'] = df['motion'].isna()    # Track sensor status

# For critical analysis: flag and include in model
df['has_missing'] = df.isna().any(axis=1)  # Create feature for missingness

Prevention: Track missing data rates per sensor as a health metric. Implement automated alerts when missingness exceeds 5%. Use “missing” as an informative feature rather than discarding it.

48.7 Case Study: Libelium Smart Agriculture Gateway Deployment

Real-World Case Study: Libelium Waspmote for Vineyard Monitoring (Rioja, Spain)

Company: Libelium (Zaragoza, Spain), an IoT hardware manufacturer specializing in sensor platforms for agriculture, environment, and smart cities.

Problem: A 120-hectare vineyard in La Rioja, Spain needed to monitor soil moisture, temperature, and humidity across 60 zones to optimize irrigation. The vineyard had no Wi-Fi coverage, unreliable cellular in valleys, and required 3+ year battery life on sensors placed among vine rows.

Deployment (2019-2022):

  • 60 Waspmote Plug & Sense sensor nodes (soil moisture + temperature + humidity)
  • 4 Meshlium edge gateways providing: Zigbee-to-HTTP protocol translation, 4GB local store-and-forward buffer, 3G/4G cellular backhaul
  • Each gateway covered 15 sensor nodes within 500m radio range
  • Sensors reported every 15 minutes using Zigbee 802.15.4

Power budget (per sensor node):

  • Battery: 6,600 mAh D-cell lithium
  • Active sensing: 15 mA for 3 seconds every 15 minutes
  • Zigbee transmit: 45 mA for 1.5 seconds per report
  • Deep sleep: 15 uA for remaining 14 min 55.5 sec
  • Average current: (3 x 15 + 1.5 x 45 + 895.5 x 0.015) / 900 = 0.14 mA
  • Battery life: 6,600 / 0.14 = 47,142 hours = 5.4 years

Gateway store-and-forward results:

  • Average cellular outage: 2-3 times/week, 10-30 minutes each
  • Data buffered per outage: ~15-30 sensor readings per gateway
  • Data loss before gateways: ~8% of readings lost
  • Data loss after gateway deployment: 0.02% (only during rare >4-hour outages)

Business impact:

  • Water usage reduced by 22% through precision irrigation ($18,000/year savings)
  • Grape quality improved – sugar content variance reduced by 15%
  • Total deployment cost: ~$45,000 (sensors + gateways + installation)
  • Payback period: 2.5 years from water savings alone

Key lesson: The gateway’s store-and-forward capability was more valuable than expected. Without it, 8% data loss created gaps in the soil moisture trend line, causing the irrigation algorithm to over-water during unknown periods. Zero data loss allowed the algorithm to confidently reduce irrigation.

48.8 Knowledge Check: Gateway Functions

48.10 Practice Exercises

Objective: Calculate battery life for IoT devices with different duty cycling strategies and optimize for maximum longevity.

Tasks:

  1. Select a target device (ESP32 or nRF52): identify power consumption in each state (active sensing: 25 mA, Wi-Fi active: 80-240 mA, light sleep: 0.8 mA, deep sleep: 10 uA)
  2. Design baseline duty cycle: active 30s/hour (sensing + processing), transmit 10s/hour (Wi-Fi/BLE), sleep remainder
  3. Calculate average current and battery life with 2500 mAh battery using the formula
  4. Optimize duty cycle: reduce active to 5s/hour, transmit to 2s/hour; recalculate battery life improvement

Expected Outcome: Baseline design yields ~6 months battery life, optimized design achieves 2-3 years (4-5x improvement). Understand that transmission dominates power budget. Learn to batch transmissions and maximize sleep time.

Objective: Build a reliable gateway that buffers data during connectivity outages and implements intelligent synchronization.

Tasks:

  1. Set up edge gateway (Raspberry Pi) with local storage (SQLite database or time-series DB)
  2. Implement data pipeline: sensors to gateway (buffer to DB) to cloud (MQTT or HTTP POST)
  3. Add connectivity monitoring: ping cloud endpoint every 10s; if unreachable, set offline flag
  4. Simulate 15-minute outage: disconnect network, accumulate 900 sensor samples (1 sample/sec); reconnect and verify all data syncs with correct timestamps

Expected Outcome: Zero data loss during outage with proper temporal ordering after sync. Measure sync latency: 900 records should upload in <10 seconds. Understand buffer sizing: 1 GB storage handles ~10 million sensor readings at 100 bytes each = days of outages.

Bella the Battery learns to take naps!

Bella the Battery was exhausted. She had been powering Sammy the Sensor and his Wi-Fi radio ALL day long without a break. “I only have enough energy for 4 days at this rate!” she cried.

Max the Microcontroller had a brilliant idea: “What if Sammy only wakes up for a few seconds each hour to take a reading, and then goes back to sleep?”

“But what about sending data to the cloud?” asked Sammy.

“You only need to turn on the radio for 2 seconds to send your reading! The rest of the time, you can be in deep sleep mode – using almost zero energy!”

They tried it, and the results were amazing. Instead of lasting 4 days, Bella could now power Sammy for over 2 YEARS!

Meanwhile, Lila the LED was working as a gateway – a translator between Sammy and the internet. “Sammy speaks Zigbee, but the cloud speaks MQTT,” Lila explained. “I translate between them. And if the internet goes down, I save Sammy’s messages until it comes back. No data gets lost!”

The lesson: Smart power management (sleeping when not needed) and reliable gateways (translating and buffering) are the keys to long-lasting IoT devices!

Key Takeaway

Transmission dominates the power budget of IoT devices. By maximizing deep sleep time and batching transmissions into short bursts, battery life can be extended from months to years. Gateways are essential for bridging non-IP sensors to the cloud, providing protocol translation, store-and-forward buffering, and security – ensuring zero data loss even during network outages.

A precision agriculture deployment uses LoRaWAN soil moisture sensors in vineyards. Target: 3+ year battery life on 2x AA batteries (6600 mAh total @ 3V). Current design lasts only 8 months. Optimize duty cycling to meet requirement.

Initial Design (8-Month Battery Life):

Activity Duration/Hour Current Draw Energy/Hour
Soil moisture sensing (capacitive) 5 seconds 25 mA 0.035 mAh
Temperature sensing (NTC) 2 seconds 3 mA 0.002 mAh
LoRaWAN transmission (SF7, 14 dBm) 2 seconds (packet TX) 120 mA 0.067 mAh
Deep sleep 3591 seconds 50 μA 0.050 mAh

Average current per hour: 0.035 + 0.002 + 0.067 + 0.050 = 0.154 mAh

Battery life: 6600 mAh ÷ 0.154 mAh/hour = 42,857 hours = 4.9 years

Wait - math says 4.9 years, but field deployment lasts only 8 months? What’s wrong?

Root Cause Analysis (Field Measurements):

  1. Actual transmission time: 5 seconds (not 2) due to join/retry overhead
    • Energy: 5s × 120 mA ÷ 3600 = 0.167 mAh (vs 0.067 planned)
  2. Temperature extremes: Vineyard sees -5°C to +40°C
    • Battery capacity at -5°C: 6600 × 0.6 = 3960 mAh (40% reduction)
  3. Sleep current higher: Actual measured = 150 μA (not 50 μA)
    • Cause: ESP32 RTC power domain + LoRa module quiescent current
    • Energy: 3591s × 150 μA ÷ 3600 = 0.150 mAh (vs 0.050 planned)

Revised Actual Energy Budget:

Activity Energy/Hour
Soil sensing 0.035 mAh
Temp sensing 0.002 mAh
LoRaWAN TX (actual) 0.167 mAh
Sleep (actual) 0.150 mAh
Total 0.354 mAh/hour

Actual battery life: 3960 mAh (cold temp) ÷ 0.354 mAh/hour = 11,186 hours = 1.3 years (close to observed 8 months considering further cold-weather losses)

Optimizations to Reach 3+ Years:

Optimization 1 - Reduce Transmission Frequency:

  • Original: Transmit every hour (24 transmissions/day)
  • Optimized: Transmit every 4 hours (6 transmissions/day)
  • Rationale: Soil moisture changes slowly (hourly data unnecessary)
  • Energy saving: 0.167 mAh/hour × 0.75 = 0.125 mAh/hour saved

Optimization 2 - Lower LoRaWAN Spreading Factor:

  • SF7 (shortest airtime) vs SF12 (longest)
  • Airtime reduction: 5s → 1.5s (on-air-time calculator)
  • Energy: 1.5s × 120 mA ÷ 3600 = 0.050 mAh per transmission
  • At 6 TX/day: 0.050 × 6 ÷ 24 = 0.0125 mAh/hour (vs 0.042 before)
  • Saving: 0.030 mAh/hour

Optimization 3 - Improve Deep Sleep Current:

  • Disable LoRa module TCXO during sleep (saves 100 μA)
  • Use ESP32 hibernation mode instead of light sleep
  • New sleep current: 10 μA (vs 150 μA)
  • Energy: 3591s × 10 μA ÷ 3600 = 0.010 mAh/hour (vs 0.150)
  • Saving: 0.140 mAh/hour

Optimized Energy Budget:

Activity Original Optimized Improvement
Soil sensing 0.035 0.035 -
Temp sensing 0.002 0.002 -
LoRaWAN TX 0.167 0.0125 (6/day, SF7) 92% reduction
Sleep 0.150 0.010 93% reduction
Total/hour 0.354 0.0595 83% reduction

New battery life: 3960 mAh (cold temp derated) ÷ 0.0595 mAh/hour = 66,555 hours = 7.6 years

Deployment Result:

  • Field test (6 months): Projected lifetime 7.2 years (meets 3+ year requirement)
  • Cost: $0 (firmware update only, no hardware changes)
  • Trade-off: 4-hour reporting interval (vs 1-hour) - acceptable for soil monitoring

Key Lessons:

  1. Always measure actual field current (don’t trust datasheets for complex sleep modes)
  2. Temperature derating is critical (battery capacity drops 40-60% at freezing)
  3. Transmission dominates power budget - reduce frequency first, then optimize airtime
Factor Direct Cloud Connection (No Gateway) Edge Gateway with Store-and-Forward Decision Threshold
Network Reliability >99% uptime, <10 min/month outage <95% uptime, hours/day outages Use gateway if outages >1 hour/week or >0.5% data loss unacceptable
Sensor Protocol IP-native (Wi-Fi, cellular, Ethernet) Non-IP (Zigbee, Modbus, BLE, LoRa) Gateway required for non-IP sensors
Latency Tolerance Tolerates 1-5 second delays Needs <100ms local decisions Use gateway if edge processing required for latency
Data Volume <1 GB/day per site >10 GB/day (pre-filter at edge) Gateway saves bandwidth if raw data >1 GB/day
Security Model Device-level TLS to cloud Gateway TLS + device firewall Use gateway for centralized security policy
Deployment Scale <100 devices >1000 devices Gateway amortizes management cost at scale
Cost per Device >$50 (justify cellular/Wi-Fi) <$10 (use low-cost radio) Gateway enables cheap sensors with radio backhaul

Quick Decision Tree:

  1. Are sensors IP-capable (Wi-Fi/cellular/Ethernet)?
    • No → Gateway required (protocol translation)
    • Yes → Continue
  2. Is network connectivity reliable (>99% uptime)?
    • No → Gateway with store-and-forward (buffer during outages)
    • Yes → Continue
  3. Is data volume >1 GB/day or real-time processing needed?
    • Yes → Gateway (edge filtering/processing)
    • No → Continue
  4. Are there >1000 devices or regulatory security requirements?
    • Yes → Gateway (centralized management/security)
    • No → Direct cloud connection (simplest architecture)

Architecture Patterns:

Pattern When to Use Example
Direct Cloud Wi-Fi sensors, reliable network, low volume Smart home thermostats
Gateway + Store-Forward Unreliable network, critical data capture Remote oil pipeline (satellite uplink)
Gateway + Edge Processing High data volume, need local analytics Factory vibration monitoring (10 kHz sampling)
Multi-Tier Gateway Very large scale, hierarchical processing Smart city (edge → fog → cloud)
Common Mistake: Ignoring Transmission Energy in Battery Life Calculations

The Error: An engineer designs a wildlife GPS collar using a 3400 mAh battery. Calculation: “GPS module draws 40 mA for 1 minute/hour. Sleep current is 50 μA. Battery life should be 3+ years!” In field testing, collars die after 3 months.

The Flawed Calculation:

Activity Duration/Hour Current Energy/Hour
GPS fix acquisition 60 seconds 40 mA 0.667 mAh
Sleep 3540 seconds 0.05 mA 0.050 mAh
Total - - 0.717 mAh/hour

Expected life: 3400 mAh ÷ 0.717 mAh/hour = 4741 hours = 6.6 months (already wrong, but gets worse)

What Was Forgotten - Cellular Transmission:

GPS collars must transmit location to cloud via cellular (2G/3G/4G). Cellular modem characteristics: - Idle (registered to network): 5 mA - Transmitting (GPRS/3G): 200-400 mA peak, 150 mA average - Transmission time: 5-10 seconds per GPS report (TCP handshake + HTTP POST + response)

Revised Calculation:

Activity Duration/Hour Current Energy/Hour
GPS fix 60 seconds 40 mA 0.667 mAh
Cellular TX (10 sec) 10 seconds 200 mA 0.556 mAh
Cellular idle 3530 seconds 5 mA 4.903 mAh
Sleep (GPS/cellular off) 0 seconds - 0 mAh
Total - - 6.126 mAh/hour

Actual battery life: 3400 mAh ÷ 6.126 mAh/hour = 555 hours = 23 days (matches field failure at 3 months with temperature derating + inefficiencies)

Cellular transmission dominated the budget:

  • GPS: 0.667 mAh (11% of total)
  • Cellular: 5.459 mAh (89% of total!)

Correct Design - Reduce Transmission:

Option 1 - Batch Transmissions:

  • Collect 24 GPS fixes in local flash memory
  • Transmit once per day (1 longer transmission vs 24 short ones)
  • Cellular modem off 23 hours/day
Activity Duration/Day Current Energy/Day
GPS fix (24x) 24 minutes 40 mA 16 mAh
Cellular TX (1x, 60s) 60 seconds 200 mA 3.33 mAh
Sleep 23.5 hours 50 μA 1.18 mAh
Total/day - - 20.51 mAh

New battery life: 3400 mAh ÷ 20.51 mAh/day = 166 days = 5.5 months (still short)

Option 2 - Use Low-Power Radio (LoRaWAN or Satellite IoT):

  • LoRaWAN transmission: 120 mA for 2 seconds (vs 200 mA for 10 seconds cellular)
  • No idle current (radio off between transmissions)
  • Energy: 120 mA × 2s ÷ 3600 = 0.067 mAh per transmission
Activity Duration/Hour Current Energy/Hour
GPS fix 60 seconds 40 mA 0.667 mAh
LoRaWAN TX 2 seconds 120 mA 0.067 mAh
Sleep 3598 seconds 50 μA 0.050 mAh
Total - - 0.784 mAh/hour

New battery life: 3400 mAh ÷ 0.784 mAh/hour = 4337 hours = 6.0 months (still needs work)

Option 3 - Combine Batching + LoRaWAN:

  • GPS fix and transmit every 4 hours instead of hourly (6 cycles/day)
  • Energy: 0.667÷4 (GPS) + 0.067÷4 (LoRa) + 0.050 (sleep) = 0.234 mAh/hour
  • Battery life: 3400 ÷ 0.234 = 14,530 hours = 20 months

Final Option - Add Solar Panel:

  • 100 mAh/day solar harvest (small 50mm × 50mm panel)
  • Net drain: 20.51 - 100 = -79.49 mAh/day (battery charges!)
  • Battery life: Indefinite (solar sustains during daylight, battery covers night)

Key Lessons:

  1. NEVER ignore transmission energy - wireless radios often dominate power budget
  2. Cellular idle current (5 mA) is 100x higher than deep sleep (50 μA) - keep modem off
  3. Batching transmissions reduces overhead (1 long TX < 24 short TXs due to handshake costs)
  4. Low-power radios (LoRaWAN, NB-IoT, satellite IoT) use 50-90% less energy than cellular
  5. Always measure actual field current with ammeter - datasheets lie about sleep current

Common Pitfalls

Radio transmission is typically the dominant energy consumer in an IoT edge node — often 10x the current draw of the sensor and MCU combined. Any power budget analysis that omits transmission power will dramatically overestimate battery life.

LoRaWAN, cellular, and Wi-Fi links in remote locations drop regularly. Without local buffering and store-and-forward, every connectivity interruption causes permanent data loss. Size the local buffer for the maximum expected outage duration.

A monolithic gateway application that crashes takes down all protocol translation, buffering, and forwarding functions simultaneously. Use containers or process supervisors so individual components can restart independently.

A device’s average current may be 1 mA but its peak during radio transmission may be 200 mA. Under-sized batteries or capacitors that cannot source the peak current will cause voltage drops and resets exactly when data needs to be transmitted.

48.11 Summary

Power management and gateway functions are critical for practical edge IoT deployments:

  • Duty cycling: Maximize sleep time and batch transmissions - TX current dominates power budget
  • Battery life: Optimized duty cycling extends battery life from months to years (4-5x improvement typical)
  • Gateway functions: Protocol translation, store-and-forward buffering, and security are essential for non-IP device integration
  • Missing data: Treat as information, not noise - use appropriate imputation and track as a health metric

48.12 Concept Relationships

Power management and gateways are critical constraints that determine edge system feasibility:

Power Optimization (This chapter):

  • Duty cycling formula extends battery life from months to years (4-5x improvement via deep sleep)
  • Transmission dominates power budget (10-100x more than sensing); batching is highest-leverage optimization

Gateway Functions (This chapter):

  • Protocol translation bridges Non-IP devices to cloud (Modbus → MQTT, Zigbee → HTTP)
  • Store-and-forward prevents data loss during network outages (24-48 hour buffer minimum)

Architecture Foundation:

Broader Context:

  • Edge Compute Patterns - Edge processing reduces transmission (saves power); offloading to fog/cloud (costs power)
  • Edge Fog Computing - Gateways often serve as fog nodes, providing both connectivity and local processing

Data Quality Impact:

Key Insight: Power and connectivity are linked – aggressive transmission schedules drain batteries fast. Vineyard case study: Gateways with store-and-forward achieved 0.02% data loss (vs 8% without), while duty cycling achieved 5.4-year battery life (vs target of 3 years). The combination makes low-power, high-reliability IoT feasible.

48.13 What’s Next

If you want to… Read this
Understand the acquisition architecture this power system supports Edge Acquisition Architecture
Learn sampling and compression strategies to reduce power Edge Acquisition Sampling and Compression
Study the broader edge data acquisition context Edge Data Acquisition
Apply edge patterns to system design Edge Compute Patterns
Return to the module overview Big Data Overview

Edge Acquisition Series:

Edge Computing:

Data Quality:

Practice:

48.14 Additional Resources