Appearance
10.3 — Connected Devices: Edge, Power and Protocols
A sensor that reports a number is easy. A million sensors that report numbers for ten years on one battery each, over networks that come and go, without becoming a security liability, is not.
This chapter is the design patterns that make the second one work, and the honest limits of each.
Everything here combines the microcontroller of Chapter 10.1 with the radios of Part 8, under the one constraint neither chapter imposed: a battery that has to last years, which turns every design question into an arithmetic question about energy.
1. Where the computation happens
The single most consequential architectural decision, and it is a spectrum rather than a choice.
Everything in the cloud. The device is a sensor and a radio; all processing happens on a server.
Simple, and it fails on four counts: the radio is the largest power consumer and it runs constantly; latency includes a network round trip; nothing works when connectivity is lost; and every measurement leaves the premises.
Everything at the edge. The device processes locally and reports only conclusions.
Better on all four counts, and it needs more capable hardware and makes updating the logic harder.
The useful principle: process as early as possible, transmit as little as possible.
Worked example. A vibration sensor on a motor, sampling at 10 kHz.
Raw transmission: 10{,}000\times2 bytes per second =20 kB/s =1.7 GB/day. Absurd for a battery device.
Edge processing: compute an FFT locally, extract the amplitude at the six frequencies that indicate specific faults — imbalance at 1× rotation, misalignment at 2×, bearing defects at their characteristic frequencies — and transmit six numbers per minute.
6\times4\ \text{bytes}\times1440=34\ \text{kB/day}
A reduction of 50,000 times, and the six numbers are more useful than the raw data because they are the diagnosis rather than the evidence.
The general form of the argument: transmit the answer, not the question. It applies to almost every sensing application, and the reason it is not universal is that extracting the answer requires knowing in advance what question matters.
The middle column is where nearly every deployed system lands, and the reason is arithmetic rather than architecture. A vibration sensor sampling at 1 kHz produces 86 million readings a day. Transmitting all of them needs a radio that is essentially always on, and section 2 shows what that does to a battery. Computing a handful of summary numbers on the device and sending those once an hour reduces the traffic by a factor of tens of thousands, and the microcontroller doing the computing is awake for milliseconds.
So the design question is never "where should the computation go" in the abstract. It is "what is the smallest message that still answers the question the system exists to answer", and the computation goes wherever it has to in order to produce that message.
2. The power budget
Chapter 3.6 gave the arithmetic. Here is what dominates in a connected device.
The radio, overwhelmingly.
| Operation | Energy |
|---|---|
| One CPU instruction | 1 nJ |
| One flash write, 4 kB | 50 µJ |
| One BLE advertisement | 30 µJ |
| One Wi-Fi association and transmission | 5 J |
| One cellular attach and transmission | 15 J |
Read those last two rows carefully. A single Wi-Fi transmission from a cold start costs as much energy as five million CPU instructions.
Which makes the design rule inescapable: compute freely, transmit reluctantly.
Worked comparison. A sensor reporting once an hour from a 3000 J coin cell:
Wi-Fi: 5\ \text{J}\times24=120 J/day, so 25 days.
Cellular NB-IoT: 15\times24=360 J/day, so 8 days — plus the modem's idle current, which makes it worse.
BLE to a nearby hub: 30\ \mu\text{J}\times24=0.72 mJ/day, plus 1 µA of sleep current at 3 V, which is 0.26 J/day.
\text{life}=\frac{3000}{0.26}=11{,}500\ \text{days}=31\ \text{years}
Longer than the battery's shelf life, so the design is finished.
The pattern that follows: a mesh of very low-power devices reporting to a mains-powered hub, which does the long-range communication. That is why every smart-home ecosystem has a hub, and why the devices that claim to connect directly to Wi-Fi are the ones that need mains power or frequent battery changes.
LoRaWAN is the exception worth naming: 10 to 15 km of range at 50 mJ per transmission, because it trades data rate for link budget using chirp spread spectrum. A sensor sending 20 bytes an hour over LoRa lasts a decade, and it needs no hub at all.
3. Choosing a network
| Technology | Range | Rate | Power | Cost |
|---|---|---|---|---|
| BLE | 10 m | 1 Mbit/s | very low | negligible |
| Zigbee / Thread | 100 m mesh | 250 kbit/s | very low | negligible |
| Wi-Fi | 50 m | 100+ Mbit/s | high | negligible |
| LoRaWAN | 15 km | 0.3–50 kbit/s | very low | low subscription |
| NB-IoT | 10 km | 60 kbit/s | low | subscription |
| LTE-M | 10 km | 1 Mbit/s | medium | subscription |
| 5G | 1 km | 1 Gbit/s | high | subscription |
The decision sequence that actually works:
- How much data, and how often? This eliminates most options immediately.
- How far from an existing gateway? Under 100 m means a local protocol; further means a wide-area one.
- What is the power source? Mains permits Wi-Fi; a battery for years does not.
- Who owns the infrastructure? A subscription is a permanent cost and a permanent dependency.
- What happens when it fails? A device that is useless without connectivity has a different risk profile from one that degrades.
And the reflex worth having: mesh networks are attractive on paper and complicated in practice. Routing, latency, battery drain on the routing nodes, and debugging a fault that appears only with a particular topology. They earn their place where the range genuinely requires them and not otherwise.
4. Protocols above the radio
MQTT — publish and subscribe through a broker. A device publishes to a topic; anything interested subscribes.
Why it dominates: the header is two bytes, it runs over TCP with a persistent connection so there is no repeated setup cost, and the last will and testament feature means the broker announces a device's disconnection automatically. It was designed in 1999 for oil pipeline monitoring over satellite links, which is why it is so frugal.
CoAP — a compact binary version of HTTP over UDP, designed for constrained devices. Lower overhead than MQTT for request-response patterns, and it maps cleanly onto REST.
HTTP — universal and heavy. A single request with TLS costs several kilobytes of handshake, which is why it is rare on battery devices and standard on mains-powered ones.
LwM2M — a device management layer over CoAP, standardising firmware updates, diagnostics and configuration. Solves the problem that every deployment otherwise reinvents.
Matter — an application layer over Thread and Wi-Fi, giving smart-home devices a common language regardless of manufacturer. Its significance is not technical but political: it is the first standard the major ecosystems all agreed to support.
5. Security
The area where connected devices have been worst, and the failures have been consequential.
The Mirai botnet of 2016 compromised hundreds of thousands of cameras and recorders using a list of 61 default username and password pairs. It launched attacks exceeding a terabit per second and took large parts of the internet offline for a day. No exploit was involved — the devices were shipped with known credentials and no requirement to change them.
The measures that would have prevented it, and that are now largely mandated:
Unique credentials per device. No default passwords, or forced change on first use. The single most effective measure, and it is now legally required in the UK, California and the EU.
Secure boot. Signed firmware, verified by a chain rooted in immutable hardware, as Chapter 10.2 described. Modified firmware does not run.
Encrypted communication. TLS with certificate verification. The common failure is disabling verification during development and shipping it, which turns encryption into an inconvenience for an attacker rather than a barrier.
Signed updates, with rollback protection so an attacker cannot install an older vulnerable version.
Minimal attack surface. No open ports, no debug interfaces, no unnecessary services. Devices have shipped with Telnet enabled and no password, repeatedly.
A defined end of life. A device that cannot be updated is a permanent liability. Stating when support ends is now a regulatory requirement in several jurisdictions, and it is a genuine improvement over the previous silence.
And the structural problem underneath all of it. A phone is replaced every three years and receives updates throughout. A thermostat lasts fifteen years, a meter twenty, an industrial sensor thirty. Supporting a device for thirty years costs money for a product sold once at a low margin, and the incentives do not align. Regulation exists because the market did not solve it, and that is the honest account.
6. Reliability in the field
Design for intermittent connectivity, not for its absence or its presence.
Store and forward. Buffer readings locally and transmit when a link is available. Size the buffer for the longest realistic outage, and decide explicitly what to discard when it fills — usually the oldest data, sometimes by decimating rather than dropping.
Idempotent operations. A command that may be delivered twice must be safe to apply twice. "Set the temperature to 20" is idempotent; "increase the temperature by 1" is not, and the difference matters the moment a network retries.
Graceful degradation. A thermostat with no cloud connection should keep running its schedule. A door lock with no connection should still open with a key. The failure mode should be defined and safe, and it should be tested rather than assumed.
Time synchronisation. A device without a real-time clock cannot timestamp its data. NTP over the network, or a battery-backed clock, or timestamps applied at the gateway. Devices that report "temperature was 22" with no time attached generate data that cannot be used.
Field updates, with the two-image fallback of Chapter 10.1. A failed update on a device inside a wall is a permanent failure.
7. Where the value actually is
The honest assessment, because the field has generated more enthusiasm than results.
Where connected sensing has clearly paid:
Predictive maintenance. Vibration and temperature monitoring on industrial machines, detecting bearing wear weeks before failure. The saving is avoided unplanned downtime, which in a production line is measured in thousands per hour, and the sensors cost tens. The economics are unambiguous.
Utility metering. Remote reading eliminates a visit, and interval data enables time-of-use pricing and rapid leak detection. Deployed at national scale.
Cold chain monitoring. A temperature logger in a pharmaceutical shipment, with an alert if it excurses. Regulatory requirement in several industries, and the value is proving compliance as much as preventing loss.
Asset tracking. Knowing where the containers, the pallets and the tools are. The saving is in not buying replacements for things that were never lost, only misplaced.
Where it has disappointed:
Consumer devices whose value is convenience. A connected kettle saves nothing and adds a security liability, a subscription and a dependency on a company that may withdraw the service. Several have been bricked by their manufacturers' shutdowns, which is a failure mode no unconnected kettle has.
Deployments without a defined question. Collecting data because it is collectable produces storage costs and no decisions. The projects that succeed start with "we need to know X in order to do Y", and the ones that fail start with "let us instrument everything."
The pattern across both lists. Value comes from acting on information that was previously unavailable and is worth acting on. Where that condition holds, the economics are strong. Where the information was already available, or where nobody acts on it, connecting the device adds cost and risk and nothing else.
8. What this volume has been
Part 1 began with charge — the property that some particles carry, and the fact that separated charge wants to recombine.
Everything since has been the controlled exploitation of that fact.
Ohm's law and Kirchhoff's laws made circuits calculable. Capacitors and inductors gave them memory, and memory gave them the ability to filter, delay and oscillate. Doped silicon gave a device whose resistance could be controlled by a third terminal, and that device — used as a switch — gave logic, and logic gave computation, and used as an amplifier it gave everything analog.
The mathematics of Part 4 gave a language for describing what a system does to a signal, and three transforms for turning hard problems into easy ones. Part 5 made those transforms computable. Part 6 used the same mathematics to make machines behave. Part 7 used it to push information through a noisy channel at a rate that Shannon proved could not be exceeded. Part 8 followed that into the systems in your pocket. Part 9 moved kilowatts instead of milliwatts using the same switching devices.
And Part 10 is where they all arrive at once.
The thread worth holding on to is that almost nothing in this volume was invented for its own sake. Every idea exists because somebody had a specific problem: Kirchhoff wanted to solve a circuit, Fourier wanted to describe heat flow in a bar, Shockley wanted an amplifier that did not need a vacuum, Shannon wanted to know how fast a telegraph could go, Nyquist wanted to know when a control loop would oscillate.
The mathematics arrived afterwards, as the tidy account of what worked. That is the ordinary order of engineering, and it is worth remembering when a subject is presented the other way round — as a set of results to be accepted before their purpose is explained.
What you should be able to do now, if the volume has done its job: pick up any electronic object, reason about what is inside it, estimate the numbers to within an order of magnitude, and explain to somebody else why it works. Not because you memorised it, but because you can rebuild it from what you know.
Every formula in this Part is derived on the next page, and fourteen worked problems follow it.
Every formula above, built from scratch
None of the results in this chapter are worth memorising, because each one can be rebuilt in under a minute from something simpler. What follows is that rebuilding, one result at a time, so the formula and the reason for it sit on the same page as the explanation that needed them.
Communication
4–20 mA loop:
\text{value}=\frac{I-4}{16}\times\text{span}+\text{zero}
4 mA is a live zero, so 0 mA unambiguously means a broken wire.
Maximum loop resistance:
R_{max}=\frac{V_{supply}-V_{transmitter(min)}}{20\ \text{mA}}
With a 24 V supply and a transmitter needing 12 V: R_{max}=600\ \Omega.
Differential signalling becomes necessary beyond about 30 cm, because a single-ended signal referenced to a distant ground carries every ground potential difference along the path.
Connected devices
Duty cycle:
D=\frac{t_{active}}{t_{period}}, \qquad I_{avg}=I_{active}D+I_{sleep}(1-D)
When D becomes small enough that I_{sleep} dominates, further duty-cycle reduction buys nothing — and the only remaining lever is the sleep current.
Store-and-forward buffer size:
N=\frac{t_{outage(max)}}{t_{sample}}
Data volume:
V=\text{rate}\times\text{size}\times\text{overhead factor}
The overhead factor is not small. A 4-byte reading sent over MQTT with TLS carries perhaps 100 bytes of framing — a factor of 25, and it is why batching many readings into one transmission matters more than compressing the readings.
LoRaWAN airtime, which determines both energy and duty-cycle compliance:
T_{symbol}=\frac{2^{SF}}{BW}
At spreading factor 7 and 125 kHz: 1.02 ms per symbol. At SF12: 32.8 ms.
A 20-byte payload takes about 60 ms at SF7 and 1.5 s at SF12 — and European regulations limit a device to 1% duty cycle, so at SF12 that permits about 24 transmissions per hour and no more.
Link budget (Chapter 7.1) applies unchanged:
P_{rx}=P_{tx}+G_{tx}-L_{path}+G_{rx}
LoRa's advantage is receiver sensitivity, reaching -137 dBm at SF12 against about -95 dBm for BLE — 42 dB more link budget, bought entirely with processing gain and paid for in data rate.
Fourteen worked problems close the volume.
What the next chapter fixes
That closes Volume III. What began as charge moving through a wire in Chapter 1.1 has become a device that senses the world, decides something about it, and tells somebody across the planet. Every layer in between was built here — and the physics underneath all of it, from the electron itself to the electromagnetic wave that carries the message, is Volume IV.