5 Energy Cost of Common Operations

Operation Hierarchy, Radio Dominance, Batching, and Local Processing Decisions

energy-power

aware

operation

costs

5.1 Start With One Expensive Radio Burst

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.

Operation-cost review starts with scale: small local work can be cheaper than repeating radio sessions, but the product trace still decides the real bottleneck.

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.

If you only need the intuition, use this rule: optimize the measured charge per useful report, not the operation that is easiest to rewrite.

Compute

Filtering, integer math, and threshold checks are often cheap enough to do locally when they reduce transmission or storage.

Sensing

The sample may be cheap, but warm-up, stabilization, analog front ends, heaters, and repeated reads can stretch active time.

Storage

Flash logging can require long active windows, erase cycles, metadata updates, and recovery work after failed writes.

Communication

Radio energy includes startup, listening, joining, retries, acknowledgments, payload, and shutdown, not only transmit bytes.

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

Operation Class

Evidence To Keep

Good Lever

Review Risk

CPU and RAM work

Added active time, clock state, memory movement, and whether the result reduces communication or storage.

Use local filtering, feature extraction, or fixed-point math when it reduces a larger measured cost.

Optimizing code that is not the measured bottleneck, or changing numerical behavior without reference checks.

Sensor work

Enable-to-valid time, warm-up, stabilization, sample count, standby current, and failed-read behavior.

Duty-cycle sensors, reuse valid context, and avoid repeated warm-ups when freshness allows it.

Reducing samples below what the application needs to detect events or maintain calibration confidence.

Storage work

Write duration, erase behavior, metadata updates, buffering policy, recovery path, and return-to-sleep delay.

Batch writes, keep compact records, avoid logging every sample, and preserve only evidence that is needed.

Saving radio energy by creating flash wear, long active windows, or data-loss risk that the service cannot accept.

Radio work

Session count, startup, receive windows, join behavior, retries, acknowledgments, payload size, signal quality, and shutdown.

Filter, aggregate, compress, batch, or defer reports when the service contract permits it.

Reducing energy by hiding alarms, delaying control data, dropping required diagnostics, or increasing retry pressure.

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

Break-Even Checks

Filtering

Does the local rule remove reports that the receiver does not need, without hiding rare events or required diagnostics?

Aggregation

Does a min, max, average, count, histogram, or event summary preserve the decision the application must make?

Compression

Does reduced payload or airtime exceed compute, memory, code-size, and error-handling cost on the target device?

Offloading

Does moving work to the edge or cloud save enough local energy after communication, privacy, reliability, and latency are counted?

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

Key Takeaway

Optimize the largest measured operation cost while protecting the service contract; every claimed saving needs a before and after whole-cycle trace.