Sensors and Actuators

Definition: Sensors read information from the physical world into a digital signal (temperature, motion, light); actuators do the reverse, taking a digital signal and producing physical motion or action (a motor, a valve, an LED).

How It Works

Sensors convert a physical quantity into an electrical signal a microcontroller can read, either digital (on/off, like a button or a PIR motion sensor) or analog (a continuous voltage, like a thermistor or a light-dependent resistor)
Actuators receive a digital or analog signal from the microcontroller and convert it into physical movement, heat, light, or sound, usually through an intermediate driver component (a transistor, MOSFET, or relay) that supplies the actual power the actuator needs
Together they form the “input and output” of nearly every IoT and embedded device, the microcontroller is the brain connecting the two
Polling reads a sensor’s value on a fixed schedule inside the main loop; interrupt-driven sensing instead lets the sensor (or a supporting circuit) signal the microcontroller only when something changes, avoiding wasted cycles checking a value that hasn’t moved
Many real sensors communicate over a shared digital protocol (I2C, SPI, or UART) rather than a single raw analog pin, returning pre-processed, calibrated readings instead of a bare voltage
Filtering (a moving average, a low-pass filter) is routinely applied between raw sensor input and any decision logic, since almost no real-world sensor produces a perfectly clean, noise-free signal
Closed-loop control (feedback control) combines a sensor and an actuator directly: the sensor continuously reports the actual state, and the actuator is driven based on the gap between that state and the desired target, forming systems like PID controllers

Under the Hood

This sense-decide-act loop repeats continuously, and it’s the same basic shape whether it’s running once a second on a battery-powered soil sensor or thousands of times a second inside a motor controller.

Worked example 1: noisy sensor readings and a moving average filter

Given: a temperature sensor’s raw readings over 5 consecutive samples are 21.3°C, 21.9°C, 20.8°C, 21.5°C, 21.2°C, jittering around a true value near 21.3°C due to electrical noise
Step: a simple 5-sample moving average = (21.3 + 21.9 + 20.8 + 21.5 + 21.2) / 5 = 106.7 / 5 = 21.34°C
Step: using the raw, unfiltered value directly in a threshold check (say, “turn on cooling above 21.5°C”) would flicker on and off as noisy samples cross the threshold randomly
Answer: the filtered average (21.34°C) stays consistently below the 21.5°C threshold, producing stable actuator behavior instead of rapid on/off flickering caused by reacting to individual noisy samples

Worked example 2: actuator current draw exceeding a pin’s rating

Given: a small DC motor actuator draws 300mA when running, connected directly to a microcontroller GPIO pin rated for a 20mA continuous / 40mA maximum output
Step: driving the motor directly would attempt to pull 300mA through the pin, roughly 15x its rated maximum, almost certainly damaging the pin’s output driver
Step: the correct design uses the GPIO pin to switch a transistor or MOSFET (drawing only a few mA to turn it on), which then switches the motor’s own separate, appropriately rated power supply carrying the full 300mA
Answer: this pattern, a small control signal switching a much larger load through a dedicated driver component, is the standard solution any time an actuator’s current draw exceeds what a microcontroller pin can safely supply directly

Worked example 3: sensor sampling rate vs power budget

Given: a battery-powered outdoor weather station needs to detect a rain event within about 1 minute of it starting, running from a small solar-charged battery
Step: polling the rain sensor every 1 second draws the sensor’s active current (say, 2mA for 10ms per read, roughly 0.02mA average) continuously all day
Step: polling every 30 seconds instead still comfortably meets the “within 1 minute” requirement while cutting the sensor’s average duty cycle by 30x, from 0.02mA average down to roughly 0.00067mA average
Answer: matching the polling interval to the actual required responsiveness, rather than polling as fast as possible “just in case,” is one of the simplest and most effective power optimizations available on a battery-powered sensing device

Common Sensor and Actuator Types

Type	Category	Typical interface	Example use
Thermistor / DS18B20	Sensor	Analog / 1-Wire digital	Temperature monitoring
PIR motion sensor	Sensor	Digital (interrupt-friendly)	Occupancy detection, security
BME280	Sensor	I2C / SPI	Temperature, humidity, pressure
HC-SR04 ultrasonic	Sensor	Digital (trigger/echo timing)	Distance measurement
DC motor	Actuator	PWM via driver circuit	Movement, fans, pumps
Servo motor	Actuator	PWM (precise angle control)	Robotics, precise positioning
Relay	Actuator	Digital on/off	Switching high-power/high-voltage loads
Solenoid valve	Actuator	Digital on/off via driver	Fluid/gas flow control

Why It Matters

This sensor-to-actuator loop is the actual point of most embedded systems, reacting to the physical world and acting back on it, not just moving data around for its own sake
Choosing polling vs interrupt-driven sensing directly affects power consumption, a battery-powered device that polls constantly wastes energy checking values that rarely change, while interrupt-driven sensing can sleep between real events
Proper filtering and driver circuitry between raw sensor/actuator hardware and control logic is what separates a reliable product from one that behaves erratically under real-world electrical noise and load
Closed-loop feedback control, sensor and actuator working together continuously, is the foundation of most real automation, from a thermostat to an industrial robot arm, not just a simple one-shot response to a single reading

Common Pitfalls

Not accounting for sensor noise, raw sensor readings are rarely perfectly clean and often need filtering or averaging before use in any decision logic
Underestimating an actuator’s power draw, motors and other actuators often need far more current than a microcontroller’s pins can safely supply directly
Polling a sensor far more often than its actual physical response time justifies, wasting CPU cycles and power for no additional useful information
Wiring an inductive actuator (a motor, a relay coil, a solenoid) without a flyback diode, letting the voltage spike generated when it’s switched off damage the driving transistor or the microcontroller
Ignoring a sensor’s warm-up or settling time, some sensors (gas sensors, some temperature sensors) need seconds to minutes after power-on before their readings are accurate, using the first reading immediately can produce badly wrong values
Mounting a sensor somewhere its reading is contaminated by the system’s own behavior, a temperature sensor placed too close to a heat-generating actuator will report the actuator’s heat, not the environment’s
Assuming an actuator responds instantly, motors, valves, and relays all have real mechanical response times, and control logic that doesn’t account for that lag can overshoot or oscillate
Not debouncing a mechanical sensor (a switch, a button), contact bounce can register several rapid digital transitions for a single physical event, corrupting anything that counts events naively

Comparison

Approach	CPU/power cost	Responsiveness	Typical use
Polling	Constant, regardless of activity	Limited by polling interval	Simple sensors, predictable-rate readings
Interrupt-driven	Low, only active on real events	Immediate, event-triggered	Buttons, motion sensors, battery-powered devices
Direct pin drive (actuator)	Cheap, but current-limited	Immediate	Small loads within pin current limits (an LED)
Driver-switched (transistor/MOSFET/relay)	Slightly more circuit complexity	Immediate	Motors, solenoids, high-current loads
PWM-driven	Cheap, precise average power control	Fast, limited by switching frequency	Motor speed control, LED dimming, servo positioning

Example

A smart thermostat reads temperature with a sensor (often a digital I2C sensor like a BME280), applies a moving average filter to smooth out noise, then actuates a relay to turn the furnace on or off based on that filtered reading compared against a target temperature. A PIR (passive infrared) motion sensor triggering a hardware interrupt to wake a battery-powered security camera from deep sleep is a common example of interrupt-driven sensing chosen specifically to maximize battery life between real events.

Smart thermostat: BME280 sensor over I2C, filtered reading, relay-driven furnace control
Battery-powered security camera: PIR motion sensor as an interrupt source, waking the device from deep sleep only on real motion
Robotics arm joint: potentiometer or encoder sensor for position feedback, servo motor as the actuator, forming a closed feedback loop

Common Interview Questions

What’s the practical difference between a digital and an analog sensor? — a digital sensor outputs a discrete on/off or pre-processed value (often over a protocol like I2C), an analog sensor outputs a continuous voltage the microcontroller’s ADC has to convert into a numeric reading itself
Why is polling sometimes worse than interrupt-driven sensing for battery-powered devices? — polling wakes the CPU on a fixed schedule regardless of whether anything actually changed, wasting power; interrupt-driven sensing lets the device sleep until a real event occurs
Why can’t most actuators be wired directly to a microcontroller’s GPIO pin? — GPIO pins are rated for a small maximum current (often 20-40mA), far below what most real actuators (motors, solenoids, relays) draw, requiring a driver component in between
What’s a flyback diode for, and why does it matter for actuators specifically? — inductive loads like motors and relay coils generate a voltage spike when switched off, the diode gives that spike a safe path to dissipate instead of damaging the switching transistor or the microcontroller
Why would a system apply filtering to sensor data before using it in a decision? — raw sensor readings usually contain noise, filtering (like a moving average) smooths that noise out so downstream logic (a threshold check, a control loop) behaves stably instead of reacting erratically to individual noisy samples
What’s the difference between calibration and filtering, precisely? — calibration removes a known, systematic bias, filtering reduces random, unpredictable noise, a sensor can need one, the other, or both depending on its error characteristics
How does PWM let a digital pin produce an “analog-like” effect? — by switching on and off rapidly at a controlled duty cycle, the load (an LED, a motor) responds to the average power delivered rather than each individual switch, appearing as a continuously variable output

FAQ

Can one sensor feed multiple decisions at once? — yes, a single filtered reading (like current temperature) can drive several independent pieces of logic (a display update, a threshold-triggered actuator, a logged data point) without needing to be read multiple times
Why do some sensors use I2C or SPI instead of a simple analog pin? — digital protocols let a sensor do its own signal conditioning and calibration on-chip and report a clean, already-processed value, and let many sensors share a small number of microcontroller pins
What’s the difference between calibration and filtering? — calibration corrects a sensor’s systematic bias against a known reference (a thermometer reading consistently 0.5°C high gets corrected), filtering smooths out random noise between individual readings, they solve different problems and are often both needed
Is PWM the same thing as an analog output? — not exactly, PWM rapidly switches a digital pin on and off at a controlled ratio to approximate an average analog-like effect (dimming an LED, controlling motor speed), most microcontrollers don’t have a true analog output pin at all
Why does actuator response time matter for control loop design? — a control loop that changes its output faster than the actuator can physically respond will overshoot and oscillate around the target instead of settling smoothly, actuator lag needs to be accounted for in the control logic’s timing

Closed-Loop Control Note

A PID (Proportional-Integral-Derivative) controller is the most common way to turn a sensor reading and a target value into a smooth actuator command, correcting proportionally to the current error, accumulated past error, and rate of change
Without feedback (open-loop control), a system just assumes an actuator command had the intended effect, which works for simple cases but drifts out of accuracy over time or under changing conditions
Closed-loop systems trade extra sensor cost and control complexity for accuracy and the ability to automatically compensate for wear, load changes, or environmental disturbance

Selecting a Sensor in Practice

A practical selection checklist: what physical quantity needs measuring, what accuracy and update rate the application actually requires (not the maximum the sensor could provide), what interface it uses (analog, digital, I2C, SPI), and what its power draw looks like both active and idle, since the cheapest or most accurate sensor on paper isn’t always the right fit once real power and integration constraints are factored in.

Dig deeper

Spot an error in this note?