In Edge Programming (EEN1097), you learned how to write concurrent, memory-safe, and resource-aware software in C++ and Rust, culminating in multi-threaded applications on the ESP32 and a first look at the Zephyr Real-Time Operating System (RTOS). In Digital and Analogue Electronics (EEN1022), you built the transistor drivers, operational-amplifier signal-conditioning stages, and analogue-to-digital conversion circuits that sit between a physical transducer and a microcontroller pin.
This book for Connected Embedded Systems (EEN1071) brings those two disciplines together and extends them across a network. A connected embedded system is a purpose-built computing device that interfaces directly to the physical world through sensors and actuators while communicating over wired or wireless networks with peer devices, local gateways, and cloud infrastructure.
The title of this book and module is deliberate. Much of the commercial literature on the Internet of Things (IoT) focuses on cloud dashboards, database ingestion pipelines, and enterprise analytics. Those tools matter, and we will use several of them in Part IV, but they cannot compensate for poor engineering at the physical boundary. If an analogue front end clips, if a sampling loop violates the Nyquist criterion, if a Linux user-space thread misses a deadline because of scheduler jitter, or if an unauthenticated sensor reading is trusted on a shared bus, the cloud platform analyses corrupted data faster. Our focus is on the engineering of the physical node and the local edge gateway: how data is captured from real hardware, how deterministic control loops act on it, how operating systems manage concurrency and hardware abstraction, and how devices collaborate securely across networks.
For most of industrial history, machines, buildings, vehicles, and clinical environments operated “dark” (Holdowsky et al., 2015)2. Their physical state, temperature, vibration spectrum, or chemical composition was unknown unless a human operator stood in front of a gauge and recorded a reading. Connected embedded systems remove that constraint by coupling physical transducers to local compute and network interfaces, allowing physical state to be measured, communicated, and acted upon continuously without human intervention.
To analyse how a connected embedded system generates engineering and operational value, Holdowsky et al. (2015)2 in the Deloitte report Inside the Internet of Things model every connected deployment as an Information Value Loop (Figure 1.1). Rather than treating an IoT device as a one-way pipe that dumps raw bytes into a server, the Information Value Loop recognises that physical information only completes its purpose when it returns to the physical world as an action.
Click a stage or a value driver to see what it covers.
Select a stage to see what happens there and which chapters build it.
Figure 1.1. The Information Value Loop, adapted from Holdowsky et al. (2015)2. Each stage is enabled by a core engineering technology and governed by three classes of value drivers: Magnitude (scale, scope, and frequency), Risk (accuracy, reliability, and security), and Time (latency and timeliness).
Each of the five stages in Figure 1.1 maps directly onto the hardware and software subsystems you will build in this book:
In any real deployment, a bottleneck at one stage stalls the entire loop. Holdowsky et al. (2015)2 group the engineering trade-offs along this loop into three value drivers:
A useful way to decide where along the network a calculation should happen is the classic DIKW hierarchy (Data → Information → Knowledge → Wisdom), usually credited to Ackoff (1989)3 and Zeleny (1987)4. Military doctrine uses a similar ladder (US Army ATP 6-01.15 calls it a cognitive hierarchy, with understanding in place of wisdom):
0x0108 read from register 0x32 of an ADXL345 accelerometer over an I²C bus.2026-11-07T18:15:00Z.First-generation IoT architectures attempted to stream raw data from every sensor directly to cloud servers. On modern industrial assets, that approach breaks down quickly: a single commercial aircraft turbine (such as the GEnx engine family) or an autonomous mobile robot fitted with depth cameras and radar generates hundreds of gigabytes to terabytes of raw sensor data per day. Transmitting raw high-rate samples over wireless links wastes radio energy, saturates network bandwidth, and introduces cloud round-trip latencies that make closed-loop control impossible.
Connected embedded systems solve this by converting raw data into compact information and local control decisions at the edge, right where the signal is captured.
Figure 1.2 puts numbers on this for the ADXL345 example above. Choose what the leaf node and the gateway send on, and compare the radio traffic, the battery life, the data sent to the cloud and whether an alarm is still raised when the internet link is down.
Choose what each tier sends on. Click a stage to see the example.
Forwards what it receives
What is given up: Every sample reaches the cloud and can be re-analysed later, at the cost shown above.
Click a stage to see its example from the DIKW hierarchy. Wisdom, the decision to throttle or stop the line, stays with the operator or a written policy.
Illustrative energy figures: about 2.9 µJ per payload byte on IEEE 802.15.4 and about 0.1 mW to compute the features. Sampling and sleep current are left out.
Figure 1.2. One accelerometer on conveyor drive 3, reduced from raw samples to information and then knowledge. Each step moved closer to the sensor cuts the radio traffic and the data sent to the cloud, at the cost of the raw waveform. The energy figures are illustrative.
The Institute of Electrical and Electronics Engineers (IEEE) defines a sensor as “an electronic device that produces electrical, optical, or digital data derived from a physical condition or event”6. In practice, as Holdowsky et al. (2015)2 note, what engineers call a “smart sensor” is a complete subsystem combining a physical transducer, an analogue signal-conditioning stage, an ADC, a microcontroller core, and a digital bus interface inside a single package (the same primer reports that average sensor prices fell from about $1.30 in 2004 to $0.60 in 2014; a complete smart sensor with a microcontroller core still costs more).
At the physical layer, sensors are divided by how they interact with energy in their environment (Holdowsky et al., 2015)2:
Alongside active radar, modern edge perception increasingly uses neuromorphic (event-based) vision sensors7. Unlike a conventional frame camera that clocks out every pixel at a fixed frame rate (e.g., 30 fps) regardless of whether anything in the scene has moved, each pixel in an event camera operates asynchronously and emits a timestamped address-event only when local log-luminance changes by a threshold. This provides microsecond temporal resolution, eliminates motion blur, achieves a dynamic range exceeding 120 dB, and reduces data volume and power consumption by two to three orders of magnitude when monitoring largely static scenes (paired with neuromorphic processors such as Intel’s Loihi 2 or BrainChip’s Akida).
The short videos below show some of these sensors working. Several are made by the sensor manufacturers, so treat those as product demonstrations: they show what the sensor can do in good conditions, not how it performs in yours.
60 GHz mmWave area scanner
A single-chip 60 GHz radar that detects and tracks people and objects in an area without a camera. Credit to @Texas Instruments on YouTube. How FMCW radar measures range and velocity is covered in Chapter 9, and you can try it in the interactive demonstration in my UNO Q radar scope article.
Contactless patient monitoring with mmWave radar
The same radar technology used for patient and elderly care: detecting people, and monitoring them without a camera or anything worn on the body. This is the non-contact vital-sign monitoring described above. Credit to @Texas Instruments on YouTube.
Event camera beside a conventional camera
A conventional frame camera and a neuromorphic (event) camera recording the same scenes. Watch for the event data rotated in 3D, with time as the third axis: it shows how sparse the events are, because only pixels that see a change report anything. Credit to @International Centre for Neuromorphic Systems, Western Sydney University, on YouTube.
Multizone time-of-flight sensor
An ST VL53L7 time-of-flight sensor in use, with no narration. It times reflected infrared pulses in up to 8 × 8 zones at once, giving a coarse depth image without a camera. My OpenMV AE3 time-of-flight doorman post uses its sibling, the VL53L8CX. Credit to @Fifi Lulu on YouTube.
Thermal sensor array
The Melexis MLX90640, a passive far-infrared array of 32 × 24 pixels, each measuring temperature. It detects people by their heat, and its resolution is too low to identify them, which makes it a useful sensor where a camera would raise privacy concerns. Credit to @Future Electronics on YouTube.
Object detection on a microcontroller
YOLOv8 object detection running from MicroPython on the OpenMV N6, a camera module built on an STM32N6 microcontroller with a neural processing unit (NPU). In my OpenMV N6 post the whole pipeline ran at about 27 frames per second, at under three-quarters of a watt. Chapter 5.2 covers microcontrollers with NPUs.
Automotive LiDAR point cloud
A Hesai AT128 LiDAR on a moving vehicle, with its point cloud beside the camera view. Each point is a distance measured by timing a laser pulse, so the scene is a 3D map rather than an image. Credit to @Hesai Technology on YouTube.
Humanoid motor control
Boston Dynamics’ Atlas humanoid robot, whose movement combines classical motor control with a whole-body controller trained by reinforcement learning (RL). It shows the other end of the loop from the sensors above: readings turned into coordinated actuator commands, fast enough to keep a robot balanced. Credit to @Boston Dynamics on YouTube. Physical AI is introduced in Section 1.2, motors in Section 7.8 and closed-loop control in Chapter 11.
Selecting a sensor for an embedded design is never just a matter of picking the part with the highest bit count on its datasheet. Following Holdowsky et al. (2015)2, six quantitative criteria govern whether a sensor is fit for a given engineering task (explored in depth with hardware calibration in Chapters 7 and 9):
| Criterion | Engineering definition | Concrete example |
|---|---|---|
| Accuracy | How closely the sensor’s reading agrees with the true physical value (closeness to ground truth). | A soil moisture sensor that reads 52% volumetric water content when the true value is 50% has an absolute error of +2%. Systematic bias can be removed by calibration. |
| Repeatability (Precision) | The ability of the sensor to produce the same output when measuring the exact same physical input repeatedly under identical conditions. | A sensor that consistently reads 52.0%, 52.1%, 52.0% has high repeatability even if it has a +2% offset; an accurate calibration curve can fix an offset, whereas poor repeatability cannot be calibrated out. |
| Range | The minimum and maximum physical values the sensor can measure without saturation or structural damage. | An ADXL345 accelerometer configured for ±2 g saturates during a sharp mechanical shock that reaches 8 g, requiring reconfiguration to its ±16 g range. In its fixed 10-bit mode that coarsens the step size; with full-resolution mode enabled it keeps about 3.9 mg per LSB on every range. |
| Noise | Random fluctuations in the output signal not caused by changes in the measured physical quantity (thermal, shot, or 1/f noise, plus coupled power-supply ripple). | High-frequency noise on an analogue distance sensor corrupts derivative calculations in a PID controller unless filtered in hardware (RC anti-aliasing) and software (Chapter 7). |
| Resolution | The smallest incremental change in the physical input that the sensor and its ADC can reliably detect. | A 12-bit ADC with a 3.3 V reference has a voltage resolution (1 LSB) of 3.3 V / 4096 ≈ 0.806 mV, though effective resolution (ENOB) is bounded by the noise floor. |
| Selectivity | The ability of the sensor to respond only to the target physical or chemical quantity while rejecting cross-sensitivity to interfering variables. | An electrochemical oxygen sensor must measure O₂ partial pressure without drifting when ambient temperature or relative humidity changes. |
Real-world connected systems rarely rely on a single sensor. In A Vision for Multisensory Intelligence: Sensing, Science, and Synergy, Liang (2026)8 highlights that while mainstream artificial intelligence has focused heavily on digital text, static images, and audio, physical systems must integrate a broad spectrum of heterogeneous signals: inertial, tactile, physiological, acoustic, chemical, thermal, and radio-frequency measurements.
Combining multiple sensors on an embedded platform introduces two foundational concepts from Liang’s (2026)8 framework that recur throughout this book:
Writing software for a connected embedded system differs from general-purpose cloud or desktop programming because every line of code executes against strict physical budgets:
Beyond the constraints of an individual microcontroller, connected embedded systems sit at the centre of a broader architectural shift identified by Chen, Cong, Mirhoseini, Kozyrakis, Mitra, LeCun, Puri, and colleagues in AI+HW 2035: Shaping the Next Decade (2026)9. For decades, computing hardware has been compute-centric, separating processing cores from memory and storage. Chen et al. (2026)9 point out that this separation has hit physical limits that they describe as the energy, memory and interconnect walls: the energy spent moving data now far exceeds the energy spent on arithmetic operations.
At the scale of a single chip, fetching a 32-bit word from off-chip DRAM consumes roughly two to three orders of magnitude more energy than performing a 32-bit arithmetic operation in an ALU. At the scale of a wireless sensor node, transmitting a single kilobyte of raw sample data over a radio link consumes orders of magnitude more energy than running thousands of multiply-accumulate (MAC) operations locally in SRAM to extract a feature or check a threshold.
Consequently, Chen et al. (2026)9 argue that the next decade of intelligent systems cannot rely on scaling brute-force cloud compute; instead, it requires cross-layer AI and hardware co-design across three coupled abstraction layers:
Understanding how to partition work across those layers, deciding what belongs in hardware, what runs in a deterministic microcontroller loop, what executes on a Linux gateway, and what is sent over the network, is the central theme of this book.
M. Weiser, “The Computer for the 21st Century,” Scientific American, vol. 265, no. 3, pp. 94–104, Sept. 1991, doi: 10.1038/scientificamerican0991-94. ↩
J. Holdowsky, M. Mahto, M. E. Raynor, and M. Cotteleer, Inside the Internet of Things (IoT): A Primer on the Technologies Building the IoT, Deloitte University Press, Aug. 2015. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
R. L. Ackoff, “From Data to Wisdom,” Journal of Applied Systems Analysis, vol. 16, pp. 3–9, 1989. ↩
M. Zeleny, “Management Support Systems: Towards Integrated Knowledge Management,” Human Systems Management, vol. 7, no. 1, pp. 59–70, 1987. ↩
Headquarters, Department of the Army, Techniques for Effective Knowledge Management, US Army Training Publication ATP 6-01.1, Mar. 2015. ↩
IEEE Standards Association, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators (IEEE Std 1451) / SEMI E133, Institute of Electrical and Electronics Engineers. ↩
G. Gallego et al., “Event-Based Vision: A Survey,” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 44, no. 1, pp. 154–180, Jan. 2022 (early access 2020), doi: 10.1109/TPAMI.2020.3008413. ↩
P. P. Liang, “A Vision for Multisensory Intelligence: Sensing, Science, and Synergy,” MIT Media Lab / arXiv preprint, 2026. ↩ ↩2
Y. Chen, J. Cong, A. Mirhoseini, C. Kozyrakis, S. Mitra, Y. LeCun, R. Puri, et al., AI+HW 2035: Shaping the Next Decade, 2026. ↩ ↩2 ↩3
© 2026 Derek Molloy, Dublin City University. All rights reserved.