The "Thing": Sensors, Actuators & ADC/DAC
A "thing" is a device that can interact with the physical world — by sensing or actuating. Forms range from dedicated hardware (sensing one phenomenon) to general-purpose devices (a smartphone).
How sensors work
Sensors detect physical changes and produce an electrical signal, output as a data stream (e.g., a phone accelerometer sampling at 100 Hz).
⭐ Sensor types — and where ADC fits (exam Q1)
Analog sensors
- Receive voltage from the device and return an adjusted voltage = the analog representation of the measurement
- Signals must be digitalized — devices only understand 0s and 1s
- Done by an ADC (Analog-to-Digital Converter)
Digital sensors
- Output a digital signal directly
- Either measure two states (ON/OFF)…
- …or use a built-in ADC
Actuators
Actuators are also transducers: they convert energy into an action (motion, switch…) upon receiving a command. Examples: LED, speakers, relay, screens, stepper motors.
- Analog actuators — interaction changes with the supplied voltage; need a DAC (Digital-to-Analog Converter) to turn 0s and 1s into a voltage.
- Digital actuators — two states by high/low voltage, or a built-in DAC.
IoT Architecture: Gateway & Edge
The "Internet" part of IoT = one or more applications that send/receive data to/from devices and process it (often with AI) to make decisions. Devices usually don't talk to the cloud directly — they go through a local gateway.
IoT Gateway
- Collects data from physically close IoT devices
- May connect to other networks (internet, other gateways)
- Possibly has an embedded DB and does local processing
- Transmits data to processing units (cloud/server)
Three-stage vs Four-stage architecture
| Stage | 3-stage | 4-stage (adds the Edge) |
|---|---|---|
| 1 | Sensors / Actuators | Sensors / Actuators |
| 2 | IoT Gateway | Gateways & Data Acquisition (A/D, measurement) |
| 3 | Cloud Server | Edge IT (analytics, pre-processing) |
| 4 | — | Data Center / Cloud (analytics, management, archive) |
Because devices generate huge volumes, IoT is also Big Data analysis — needing ingestion → transformation → storage → presentation pipelines.
Communication & Interoperability
Each IoT device may use very different networking interfaces to reach the gateway — Bluetooth, Zigbee, Wi-Fi, Z-Wave, LoRaWAN, Sigfox, Cellular, NFC, MQTT, OPC-UA… Each modality has its own peculiarities, so integration is challenging.
Types of IoT
Consumer
Personal use: smart speakers, heating, robot vacuums, appliances
Commercial
Workplaces: occupancy/motion sensors, cold-storage temp, vehicle localization
Industrial (IIoT)
Machinery control & predictive maintenance: temperature, vibration, rotation speed
Infrastructure
Smart cities/grids: pollution, traffic, energy consumption
A quick history (good for "which is FALSE" traps)
- 1982 — first IoT device: a Coca-Cola vending machine on ARPANET (check stock & if drinks were cold)
- 1990 — a toaster, first device connected to the Internet
- 1999 — Kevin Ashton coins the term "Internet of Things"
- ~2008–2010 — connected devices outnumber people
Sensing in IoT
Sensors/actuators can be embedded in resource-limited devices or in personal smart objects (phones, watches, glasses), interconnected into sensor networks.
Physical sensor categories
Inertial
Acceleration & rotation on 3 axes: accelerometer, gyroscope, gravity, rotational vector
Environmental
Air temp, pressure, illumination, humidity: barometers, photometers, thermometers
Position
Physical position: orientation sensors, magnetometers
Mobile & wearable devices
Mobile/wearables are IoT devices too — they provide sensing, gateway / opportunistic data exchange, an interface, a way to identify subjects in an environment, and a way to know their goals/preferences. Built-in sensors: inertial, environmental, location (GPS), and virtual sensors.
Wearable biosensors: ECG, body temperature, blood pressure, heart rate, oxygen saturation, perspiration, skin conductivity, blood glucose, EMG, EEG.
Challenges of IoT devices
- Limited resources (energy, CPU, memory)
- Different types of interfaces
- High variance in connectivity
- Variable location
Sensor Data Management
Analysing sensor data is important — but collecting it is itself a hard problem: data collection is energy-costly, may be incomplete/erroneous, sensors may be unavailable, it often needs real-time and distributed processing.
⭐ Energy consumption — the golden rule
Two cost drivers: Data Generation Costs (reading a sensor; depends on the phenomenon) and Communication Costs (transmitting to the gateway — dominant).
The four data-management tasks
| Task | Goal | Where |
|---|---|---|
| Data Acquisition | Efficiently acquire samples from the sensor network | Locally, on the sensor network |
| Data Cleaning | Identify & remove noisy/erroneous readings (failures, lost comms) | After acquisition (e.g., base station) |
| Query Processing | Answer queries accessing/generating minimal data | Network / base station |
| Data Compression | Summarize / eliminate redundancy in large data | Network / storage |
Acquisition techniques
- Duty cycling: transmitting is costly → keep the antenna in sleep mode most of the time, with coordinated sleep/wakeup scheduling.
- Mobility-based: exploit mobile gateways/nodes (carried by people, cars, animals) to better distribute transmission costs.
- Sampling: don't use all the signal — sample at a frequency that's still representative (HAR accelerometer may give 200 Hz, but 50 Hz is often enough).
- In-network query processing: instead of centralizing, build an overlay network and aggregate in intermediate nodes (avg, min/max) to cut transmitted data.
Compression
Approximate a sensor data stream with a set of functions. Regression, transformation and filtering exploit spatio-temporal correlations; orthogonal transforms (Fourier, wavelet) reduce dimensionality.
⭐ Data Acquisition: Push vs Pull
This is the topic behind simulation exam Q16. Get the direction right and you've got the question.
🔄 Pull-based
- The user/gateway defines the interval and frequency of acquisition
- Sensors are queried on demand
- Declarative style:
SELECT … SAMPLE INTERVAL 1s FOR 10s - Simple, but can waste energy querying when nothing changed
📤 Push-based
- Gateway & sensors agree on a model of expected behavior (e.g., usual daily temperature curve)
- Sensors transmit only when values deviate from the model
- Energy-efficient — silence means "as expected"
- Models: linear prediction (temporal only, per-sensor) or Markovian (complex spatial dependencies among sensors)
Why push saves energy
Both base station and sensor network keep the same probabilistic model in sync. As long as readings match the model, nothing is transmitted; only deviated sensor values + model updates travel over the network — directly attacking the communication cost that dominates the energy budget.
Final Quiz — Exam Style
7 MCQs with instant feedback + 2 open-ended questions. Q1 and Q6 are modeled directly on the simulation exam.
a) Sensors are typically battery-powered and may sit in inaccessible locations, so battery life determines system lifetime. The two cost drivers are data generation cost (reading the sensor — depends on the phenomenon) and communication cost (transmitting to the gateway), the latter being dominant: transmitting 1 bit costs about as much as 1000 CPU operations.
b) Examples: (1) Duty cycling — keep the radio antenna asleep most of the time with coordinated sleep/wakeup scheduling, since transmitting is the costly part. (2) In-network query processing / aggregation — aggregate (avg, min/max) at intermediate nodes so far less data is transmitted. Also valid: push-based acquisition (transmit only deviations from a shared model), sampling at a lower-but-representative frequency, and compression (Fourier/wavelet).
a) In pull-based acquisition the user/gateway decides the interval and frequency and queries the sensors (e.g., SAMPLE INTERVAL 1s FOR 10s). In push-based acquisition the sensors transmit on their own, sending data only when readings deviate from an agreed model — making it more energy-efficient.
b) The model is a shared expectation of sensor behavior kept in sync between the sensor network and the base station; while readings match it, nothing is transmitted, so only deviations + model updates travel the network. Linear-prediction models (X̂ᵗ⁺¹ = αX̂ᵗ + β) use only temporal features and treat each sensor independently; Markovian models capture complex, also spatial dependencies among sensors via an initial state distribution and transition probabilities.