5 Energy Cost of Common Operations

5.1 Start With One Expensive Radio Burst

Prove Which Complete Operation Spends the Charge

Picture a device whose small message triggers a long wake, connection wait, retry, and receive window. Counting only the send time hides most of the cost.

Firmware means the software stored on a device that controls its hardware. Tie its version to the exact sleep, wake, sense, compute, store, send, wait, retry, and return sequence.

Measure single, batched, weak-link, failed, and recovered operations. Keep the current trace, state times, bytes, retries, energy, firmware, and useful result so another person can compare the cycles.

This check covers one board and workload, not every battery or network. The deeper sections develop operation hierarchy, amortization, measurement, batching, and design trade-offs.

A sensor reading may cost almost nothing until the device sends it. Then the radio wakes, negotiates, transmits, waits, and sometimes retries. That one burst can dominate the whole budget.

Use this chapter to compare operations as complete cycles, not isolated instructions. The goal is to decide when sensing, computing, storing, compressing, or batching saves more energy than it spends.

5.2 Operation Cost Is A Whole-Cycle Question

Energy cost is the charge or energy a device spends to complete useful work, not the cost of a single instruction or packet in isolation. An IoT node pays for wake-up, sensor settling, computation, storage, radio startup, receive windows, retries, acknowledgments, and the return to sleep. The biggest consumer is often outside the code line that feels most visible.

The safest hierarchy is qualitative. Simple CPU work and RAM access are usually small compared with radio sessions, long sensor warm-up, flash writes, or leakage that remains active during sleep. The exact ranking still has to be proven on the real board, firmware, radio conditions, and service pattern.

Energy per bit is not the same as total transmit power. A high-throughput, short-range link can have a low nJ/bit number because its fixed startup cost is amortized over many bits, while a low-throughput link can spend more energy per bit even at lower instantaneous power. That does not make "always transmit" the right policy. If local filtering, compression, or feature extraction removes a radio session, it can beat sending raw samples even when the compute itself is not free.

Order-of-magnitude figures make the amortization effect concrete. A GSM link transmitting at 30 dBm spends on the order of 10,000 nJ/bit; 802.15.4 at 16 dBm is closer to 3,500 nJ/bit and the same radio turned down to 0 dBm is closer to 1,000 nJ/bit; Bluetooth at 15 dBm is closer to 300 nJ/bit; and a high-rate 802.11g link at 16 dBm can fall to roughly 50 nJ/bit because its much higher bit rate amortizes the fixed radio-on cost over far more bits per second. The ranking is not simply "lower power number wins" -- an 802.11g radio can draw over 1 W while transmitting, more instantaneous power than GSM, but it moves so many more bits per second that its cost per bit is smaller. Use measured nJ/bit for the radio actually on the board, not a name-brand assumption, before deciding whether a payload is cheap or expensive to send.

5.3 Charging and Communication Energy

Inspect Figure 5.1 to compare equal capacitor and final-voltage conditions before attributing the saving to the stepping method.

Read Figure 5.1 across the four labelled plateaus ending at 1.30 V. Their increments are 0.45, 0.30, 0.27, and 0.28 V, so FOUR-STEP LOSS is $\tfrac12(100\,\mathrm{nF})(0.45^2+0.30^2+0.27^2+0.28^2)=22.19\,\mathrm{nJ}$. SINGLE JUMP uses the same capacitance and final voltage: $\tfrac12(100\,\mathrm{nF})(1.30^2)=84.5\,\mathrm{nJ}$, or about $3.81\times$ the stepped loss.

Then inspect Figure 5.2 to count the operations and memory movements introduced when local processing removes radio bits.

Read SENSOR → ADC → COMPUTE? → RADIO in Figure 5.2, then compare 8-bit add with 32-bit DRAM read on the logarithmic ladder. The DECISION TEST requires saved transmission energy to exceed computation and memory movement, using the actual link’s measured nJ per bit.

The purpose of the figure at Figure 5.3 is to test a specific operation cost is a whole-cycle question boundary: Orders of Magnitude Difference must remain consistent with pJ.

Use the hierarchy as a triage guide, not a universal law. A filter that takes 20 ms at 8 mA costs 8 mA x 0.020 s = 0.16 mA-s. Avoiding one retry-prone radio session at 120 mA for 300 ms saves 120 mA x 0.300 s = 36 mA-s, over 200 times larger before receive windows and join overhead are counted. If the filter does not remove a session, shorten active time, or reduce storage, then the same local work may be irrelevant.

5.4 Build The Operation-Cost Ledger

An operation-cost ledger turns a vague optimization idea into a reviewable decision. It records the useful information the system must deliver, the operations used to deliver it, the cost driver in the measured trace, the proposed change, and the service constraint that must not be broken.

The ledger should compare alternatives at the level of useful outcomes. Sending one report after local filtering can be better than sending raw samples, but only if the report still satisfies freshness, loss, safety, diagnosis, and downstream-analysis needs. Batching can amortize radio overhead, but it can also increase latency or lose more data during a reset.

5.5 Decision Record Template

Useful report:
Current measured cost driver:
Proposed local work:
Radio/storage/sensor cost reduced:
Latency/freshness/loss constraint:
Before trace:
After trace:
Decision:
Retest trigger:

5.6 Why Local Work Can Save Energy

Local work saves energy when it removes a larger downstream cost. A filter can be worthwhile if it prevents a radio session. Compression can be worthwhile if saved airtime and retries exceed compute and memory cost. Aggregation can be worthwhile if a summary is as useful as raw samples. The same choices fail when they add active time without reducing expensive operations or when they damage the information the system needs.

The useful comparison is not CPU cycles versus bytes in the abstract. Compare charge per useful report under the same firmware, sensor configuration, radio environment, and error policy. If the optimization changes retry behavior, storage pressure, clock state, or wake duration, include those effects in the full-cycle trace.

A useful break-even test is added local charge < removed downstream charge, with service quality held constant. For example, compression that adds 15 ms at 12 mA costs 0.18 mA-s. If it prevents an 80 mA, 250 ms extra radio retry, it saves 20 mA-s and is worth measuring further. If retries, receive windows, and active duration stay unchanged, the smaller payload has not yet proved an energy win.

5.7 Break-Even Checks

5.8 Retest Triggers

• Radio firmware, payload format, join policy, retry policy, signal environment, or antenna placement changes.
• Sensor warm-up time, sample rate, calibration policy, or valid-data rule changes.
• Storage buffering, flash layout, record format, or crash-recovery policy changes.
• Clock configuration, compiler settings, numerical representation, or firmware scheduling changes.
• The service contract changes for latency, freshness, alarm behavior, audit trail, or data retention.

5.9 Bounded Scenario: Remote LoRa Station Cluster

The existing vineyard case already teaches that sensing can create operational value. Repeating its water-saving story would add little. This scenario asks a different question: what does a small remote monitoring cluster cost to keep powered, reachable, and trustworthy for its full service life? It treats every number as a replaceable planning assumption and keeps security operations visible instead of hiding them inside “gateway cost.”

The security budget must buy concrete work: unique device and gateway identities, protected key storage, authenticated updates, disabled unused services and ports, least-privilege backhaul, credential rotation, log retention, vulnerability response, and a recovery test. The power budget must come from measured normal, retry, join, fault, and cold-temperature traces. The cost decision is acceptable only if it records who owns each recurring action and what happens when a station is unreachable, a battery misses its service interval, or a gateway credential is suspected compromised.

5.10 Arithmetic, Memory, and Radio Energy Hierarchy

“Compute locally or transmit?” is only answerable after putting arithmetic, data movement, and radio work in the same unit. Energy per operation is that common unit. The table below records one published-style 45 nm CMOS example; it is useful for scale, not as a substitute for measurements on a modern target.

Walk down the table rather than reading across it. A 32-bit SRAM read costs about 50 times the listed 32-bit integer add. The DRAM read costs about 6,400 adds, or about 173 of the listed 32-bit floating-point multiplies. The hierarchy is therefore not simply “integer cheap, floating point expensive.” Once operands travel to distant memory, movement can dominate either arithmetic choice.

Now connect that hierarchy to an illustrative radio cost of 10 nJ per transmitted bit:

At that radio cost, suppressing one transmitted bit creates room for roughly $10{,}000/640=15.6$ DRAM-word reads, or many thousands of simple integer operations. That does not mean every compression pass wins. The decision must include the reads and writes used by the algorithm itself:

Local processing is an energy win only when $E_{saved}>0$ and the extra active time, latency, accuracy loss, and memory footprint remain acceptable. For example, a filter that performs 2,000 integer adds at 0.1 pJ, makes 100 SRAM reads at 5 pJ, and avoids 80 radio bits at 10 nJ/bit has an idealized compute-and-memory cost of only $0.2+0.5=0.7$ nJ against 800 nJ of avoided transmission. If the same filter spills 2,000 words to DRAM, data movement becomes $2{,}000\times640$ pJ $=1.28\ \mu$J and reverses the result.

Use this as the review sequence: count bits avoided; count every memory level crossed; count arithmetic at its actual width; add radio startup, listening, acknowledgement, retry, and tail energy; then confirm the result with a whole-cycle trace. The numerical hierarchy tells you where to look. The measured trace decides whether the optimization survives contact with the real platform.

5.11 Summary

• Operation-cost review compares the whole duty cycle: wake, sensing, compute, storage, radio behavior, retries, and return to sleep.
• Simple local work is often worthwhile when it removes radio sessions, payload, storage, or sensor activity that the service does not need.
• Radio cost includes startup, listening, joins, acknowledgments, retries, payload, and shutdown, not only the bytes transmitted.
• Batching, filtering, aggregation, compression, and offloading must preserve latency, freshness, loss, alarm, and evidence requirements.
• The final proof is measured charge per useful report before and after the change.

5.12 See Also