9 Edge Acquisition: Power and Gateway Functions

9.1 Overview

This first route builds the power ledger and defines the translation, buffering, and security functions a non-IP gateway must own.

This is part 1 of 2. Continue with Edge Acquisition: Missing Data and Field Design for the second focused route.

9.2 Start With the Story

Spend the Battery on the Field Decision

Picture a vineyard unit that checks soil once each hour and sends a warning only when plants may be at risk. The team wants a full season of life, but a bench test shows only the current used during one quick reading.

List every state in one day: sleep, wake, sense, compute, send, listen, retry, and recover. A duty cycle is the share of time spent active compared with the full period. Multiply each state current by its time. Add the rare bad day when the link is weak or the unit restarts.

A protocol is the agreed set of rules used for an exchange. LoRaWAN is a long-range, low-power set of network rules for small radio messages. Its reach can help a field unit, but retries, receive windows, and poor coverage still spend energy. Measure them at the site.

A gateway is the unit that links the field radio network to another service. Turn it off during the trial. The sensor should keep the fact with its source, time, unit, and quality. It should send later without hiding the gap or sending the same event as new.

Change one factor at a time. Shorten the report period. Add a retry. Cool the battery. Delay the outside link. Compare life, warning time, lost facts, and recovery work against written pass limits.

Put the result in a daily table that a field worker can read. Show the normal day, weak-link day, and restart day. Name the largest cost and the next change worth testing. Keep the raw measure beside the estimate.

Repeat the table after the case, antenna, battery, or code changes. A small change can alter wake time or cause more retries. The old life claim must not follow the product without a new check.

This first budget is a useful estimate, not a life guarantee. Practitioner builds the full state and gateway plan. Under the Hood follows missing data, admission rules, battery chemistry, and failure cases that a simple average cannot show.

Picture an IoT team using the ideas in Edge Power and Gateways during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

9.3 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

9.4 Prerequisites

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

• Edge Data Acquisition: Architecture: Understanding device categories and connectivity paths
• Edge Data Acquisition: Sampling and Compression: Data reduction techniques for bandwidth optimization
• Basic electrical concepts: Familiarity with current, voltage, and power calculations

9.5 Power Management and Duty Cycling

Start with the device: every gateway promise depends on a node that wakes, measures, transmits, and sleeps again.

9.6 Power States

Most IoT microcontrollers support multiple power states:

9.7 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}}$

9.8 Example Calculation

Scenario: ESP32 with 2500 mAh battery

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

9.9 Optimized Design

Reduce active to 5 seconds, transmit to 2 seconds:

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)

9.10 External Nano-Power Timer and Load Disconnect

Deep sleep still leaves the MCU, regulator, sensor bias network, and board leakage connected to the battery. When the sampling interval is minutes or hours, an external timer can make a stronger boundary: it powers the load only for one acquisition transaction, then physically disconnects that load after firmware reports completion.

A TPL5110-class arrangement has two power domains. The timer remains connected to the battery at nanoamp-class quiescent current. Its DRV output controls a MOSFET or load switch feeding the MCU, sensors, and radio. The MCU’s DONE output returns to the timer. Keep those signals distinct from a reset pin: DRV controls energy to the entire load, while a low-to-high DONE transition is the firmware’s declaration that durable work has finished. For the TPL5110 specifically, DRV low turns the external MOSFET on and DRV high turns it off; other timer/load-switch combinations may use the opposite polarity.

Follow one cycle:

1. Off interval. DRV holds the TPL5110’s MOSFET off, and only timer, switch leakage, and any deliberately retained domain draw current.
2. Timed wake. At the programmed interval, the TPL5110 drives DRV low; the MOSFET conducts, the rail rises, and the MCU starts from reset rather than resuming retained RAM.
3. Acquire and transmit. Firmware initializes peripherals, samples the sensor, records a timestamp or sequence, and attempts the bounded communication policy.
4. Commit state. Before shutdown, firmware stores only the state required for the next cold boot and verifies that the write or queued hand-off completed.
5. Assert DONE. A clean low-to-high transition tells the timer to drive DRV high. The MOSFET removes power until the next interval.

The energy ledger must include the always-on timer and switch leakage. For a period $T$, load-on time $t_{on}$, load current $I_{on}$, timer current $I_t$, and off-state leakage $I_{leak}$,

Suppose the load draws 25 mA for 0.50 s every 600 s, the timer draws 0.035 microamps, and the disconnected load path leaks 0.10 microamps:

The active burst still dominates, but the example shows why board leakage belongs beside the timer data-sheet number. A 10 microamp regulator or programming interface left across the battery would materially change the result even though the MCU is physically off.

For the TPL5110, a missing DONE does not leave the load on indefinitely. The device holds the load on for the programmed interval minus roughly 50 ms, then forces DRV high for the final 50 ms before the next cycle. That maximum-on window is a hardware recovery boundary, but it may be far longer than the application’s safe fault time. Choose the interval so legitimate cold boot, sensing, and radio retries fit, then add an independent watchdog when a hung actuator or high-current radio must be cut off sooner. Record both the normal DONE time and the forced-off time in the fault test.

Phoebe’s Field Notes: Why Battery Life Is a Charge Ledger

The mathematical gist. The baseline hourly ledger spends 0.208 mAh sensing, 0.333 mAh transmitting, and 0.00989 mAh sleeping, for 0.552 mA average and about 189 days from 2,500 mAh. The optimized 5-second sense and 2-second transmit states average about 0.111 mA and reach roughly 2.56 years. Cold derating, leakage, and load-voltage sag must still be subtracted.

Math Bridge · guided foundationsHow does a ten-second radio burst become a battery-life result?Let Data Dora audit charge, average current, derating, voltage sag, and lifetime. Learn the maths

9.11 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.

9.12 Knowledge Check: Battery Life

9.13 Quiz 1: Battery Life Calculation

9.14 Gateway Functions for Non-IP Devices

The hardware photograph in Figure 9.1 grounds the gateway discussion in its two physical boundaries: field-side interfaces and an IP-capable processing and network side. Inspect the visible connector groups before assigning software responsibilities to the board.

Photo: Laserlicht, CC BY-SA 4.0

Read Figure 9.1 from the GPIO header to the processor, memory, USB, and Ethernet interfaces. The header can meet sensors or controllers through local electrical interfaces; the Linux-capable compute and network ports can buffer records, translate protocols, keep logs, and establish secure upstream sessions. The board itself does not guarantee any of those behaviors. It connects the chapter’s running narrative to implementation: gateway responsibility comes from the software, credentials, storage, and failure policy built across those two sides.

Once the node can survive on battery, ask whether its data can cross protocols and outages.

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

9.15 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)

9.16 Data Buffering

A field gateway needs a buffering contract before an outage proves it missing. Figure 9.2 follows one vineyard reading from durable append through bounded storage, oldest-first replay, and cloud reconciliation.

In Figure 9.2, Append preserves sensed_at and sequence before the link fails, while Bound makes the 96 kB limit operational rather than silently overwriting evidence. After Reconnect, the durable ACK cursor advances only on receipt; Reconcile then prevents a replayed noon value from masquerading as a current sample.

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

9.17 Security Functions

Energy optimisation becomes unsafe when it removes the mechanisms that make a command dependable. Figure 9.3 puts the secure wake and recovery work inside the same charge ledger as sleep and radio transmission.

The Wake defensibly card in Figure 9.3 checks brownout, secure boot, and a monotonic counter before the valve rail is enabled. Recover safely reserves enough energy for signature verification, flash writing, reboot, and reporting, making security and rollback cross-cutting power requirements rather than optional radio overhead.

The gateway diagram in Figure 9.4 brings protocol translation, buffering, and security into one route so the trust checks can be placed before data or commands cross the boundary.

• Encrypt data before transmission to cloud
• Authenticate devices and manage credentials
• Filter and validate incoming commands

Inspect Figure 9.4 now to see where those checks sit relative to protocol translation, outage buffering, and the cloud-facing session.

Trace Figure 9.4 from the non-IP protocols through translation and buffering to the cloud-facing IP path. Then inspect the security layer across that flow: device identity belongs at admission, encryption protects the upstream session, validation constrains payloads, and buffering must preserve protected records during outages. Security is therefore not a final wrapper around translated data. This completes the gateway narrative by showing that semantic preservation, outage recovery, and trust enforcement are simultaneous responsibilities at the same boundary.

9.18 Fail-Closed Gateway Admission Control

Read the Fail-Closed Gateway Admission Control material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter’s running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.

For industrial or safety-critical gateways, security should start before the protocol bridge accepts a device. A fail-closed gateway uses a default-deny policy:

1. Check the device identity first, such as an approved MAC address, serial number, certificate, or provisioning record.
2. Reject and log unknown devices before TLS or application traffic begins.
3. Start the TLS or mTLS handshake only for approved devices.
4. Apply command filtering and payload validation before forwarding data to the cloud or issuing actuator commands.

Encryption protects data confidentiality, but it does not prove device identity by itself. A gateway that validates identity, encrypts transport, and rejects unknown devices before forwarding traffic has a smaller attack surface than a gateway that only wraps every connection in TLS.

9.19 Continue to Part 2

Continue with Edge Acquisition: Missing Data and Field Design.