Imagine a leak detector hidden under a sink. A dashboard notification may be useful later, but the device needs a local story too: flash, beep, show status, and make the warning impossible to miss in the place where the problem happens.
Visual and audio actuators turn invisible system state into human feedback. Choose LEDs, displays, buzzers, tones, and patterns around attention, power, environment, and how quickly a person must understand the message.
This chapter’s 8-bit PWM dimmer and 5 kHz LED switching rate are not arbitrary firmware settings; they sit against two hard physical limits from information theory. First, chopping a continuous brightness command into 256 discrete duty-cycle codes is exactly the same rounding operation an ADC performs on a sensor voltage – it leaves a quantization “noise floor” that a formula can predict, and here the true sensor doing the rounding-back-out is the human eye, whose own brightness discrimination has a floor too. Second, switching an LED on and off is itself a sampled process from the point of view of anything that samples light in time – your eye barely notices, but a rolling-shutter camera samples at its own frame rate, and if the PWM frequency and the camera’s sample rate are not chosen carefully, the fast switching folds down into a slow, very visible beat – the same spectral-folding failure a badly chosen ADC sample rate produces on a sensor signal.
Quantizing an \(N\)-bit duty-cycle code over full-scale range \(\mathrm{FSR}\) leaves a step and a noise floor:
\[q = \frac{\mathrm{FSR}}{2^{N}}, \qquad \text{noise power} = \frac{q^{2}}{12}\]
For a full-scale signal, the ratio of signal power to that noise floor reduces to the standard ADC/DAC result (the \(\mathrm{FSR}\) terms cancel):
\[\mathrm{SNR}(\mathrm{dB}) = 6.02N + 1.76\]
Any process that samples a time-varying signal at rate \(f_s\) folds an input component at \(f_{in}\) down to an aliased frequency inside the baseband:
\[f_{alias} = \left| f_{in} - \mathrm{round}\!\left(\frac{f_{in}}{f_s}\right) f_s \right|\]
which is zero only when \(f_s \geq 2f_{in}\) places \(f_{in}\) outside the fold range entirely – the Nyquist criterion.
After completing this chapter, you will be able to:
Think of how a microwave beeps when your food is ready, or how a traffic light changes color to tell you when to stop or go. Visual actuators (like LEDs and screens) and audio actuators (like buzzers) are the ways IoT devices communicate with people. They turn invisible data into something you can see or hear, making smart devices feel responsive and helpful.
This chapter has four linked stops:
Checkpoints recap the main decisions as you go. Existing calculators, quizzes, and deep dives are optional breathers when you want to test the numbers.
LEDs (Light Emitting Diodes) are the simplest visual actuators, used for indicators, status lights, and ambient lighting.
Calculate the required series resistor for safe LED operation:
You might think dimming an LED means reducing voltage, but that’s not how it works. Here’s the trick:
Step 1: On/Off at High Speed - Instead of lowering voltage (which would change LED color), the microcontroller rapidly switches the LED fully ON and fully OFF – thousands of times per second (typically 1-20 kHz).
Step 2: Vary the Duty Cycle - - 100% brightness = LED on 100% of the time - 50% brightness = LED on 50%, off 50% (alternating) - 10% brightness = LED on 10%, off 90%
Step 3: Your Eye Averages It - The switching happens so fast (>500 Hz) that your eye perceives a smooth brightness level, not flickering. It’s like spinning a fan – individual blades blur into a circle.
Real-World Analogy: Imagine a light switch you flick on and off 1,000 times per second. If you keep it on 70% of the time (on for 0.7ms, off for 0.3ms in each 1ms cycle), your eye sees 70% brightness – even though the LED is always either fully ON or fully OFF, never “dim.”
Why This Method?
Calculate power consumption and energy savings for LED brightness control:
Example: At 50% PWM brightness (duty cycle = 0.5), an LED with forward voltage \(V_f = 2.1\) V and \(I_f = 20\) mA appears half as bright and uses half the power. Average current is \(I_{avg} = 0.5 \times 20 = 10\) mA, so power is \(P = V_f \times I_{avg} = 2.1 \times 0.01 = 0.021\) W. Over 24 hours, this saves \(E = (0.042 - 0.021) \times 24 = 0.5\) Wh compared to full brightness.
#define LED_PIN 25
void setup() {
// Configure PWM for LED dimming
ledcSetup(0, 5000, 8); // Channel 0, 5kHz, 8-bit resolution
ledcAttachPin(LED_PIN, 0);
}
void loop() {
// Fade in
for (int brightness = 0; brightness <= 255; brightness++) {
ledcWrite(0, brightness);
delay(10);
}
// Fade out
for (int brightness = 255; brightness >= 0; brightness--) {
ledcWrite(0, brightness);
delay(10);
}
}// RGB LED pins (common cathode)
#define RED_PIN 25
#define GREEN_PIN 26
#define BLUE_PIN 27
void setup() {
// Configure PWM for each color channel
ledcSetup(0, 5000, 8); // Red
ledcSetup(1, 5000, 8); // Green
ledcSetup(2, 5000, 8); // Blue
ledcAttachPin(RED_PIN, 0);
ledcAttachPin(GREEN_PIN, 1);
ledcAttachPin(BLUE_PIN, 2);
}
void setColor(int red, int green, int blue) {
ledcWrite(0, red);
ledcWrite(1, green);
ledcWrite(2, blue);
}
void loop() {
setColor(255, 0, 0); // Red
delay(1000);
setColor(0, 255, 0); // Green
delay(1000);
setColor(0, 0, 255); // Blue
delay(1000);
setColor(255, 255, 0); // Yellow
delay(1000);
setColor(0, 255, 255); // Cyan
delay(1000);
setColor(255, 0, 255); // Magenta
delay(1000);
setColor(255, 255, 255);// White
delay(1000);
}
Checkpoint: LED Feedback
You now know:
With single LEDs and RGB packages under control, the next question is how to scale beyond three channels without spending one GPIO per color.
Addressable LEDs allow individual control of each LED in a strip using a single data wire.
Calculate power requirements for addressable LED strips:
Note: WS2812B LEDs draw approximately 60mA at full white (all three RGB channels at maximum). Single colors draw ~20mA. Always add a 20% safety margin to your power supply rating.
#include <Adafruit_NeoPixel.h>
#define LED_PIN 18
#define NUM_LEDS 30
Adafruit_NeoPixel strip(NUM_LEDS, LED_PIN, NEO_GRB + NEO_KHZ800);
void setup() {
strip.begin();
strip.setBrightness(50); // 0-255 (limit current draw)
strip.show();
}
void loop() {
rainbow(10); // Cycle all hues
colorWipe(strip.Color(0, 255, 0), 50); // Green wipe
colorWipe(strip.Color(127, 0, 0), 50); // Red wipe
}
// Animate a rainbow across the strip
void rainbow(int wait) {
for (long hue = 0; hue < 65536; hue += 256) {
for (int i = 0; i < strip.numPixels(); i++) {
int pixelHue = hue + (i * 65536L / strip.numPixels());
strip.setPixelColor(i, strip.gamma32(strip.ColorHSV(pixelHue)));
}
strip.show();
delay(wait);
}
}
// Fill strip one pixel at a time
void colorWipe(uint32_t color, int wait) {
for (int i = 0; i < strip.numPixels(); i++) {
strip.setPixelColor(i, color);
strip.show();
delay(wait);
}
}An LED matrix block packs many ordinary LEDs into a row/column grid. An 8x8 matrix has 64 emitters, but the package usually exposes row and column pins rather than 64 separate LED pairs. The controller lights a pattern by selecting one row or column at a time fast enough that the eye sees a stable image. That multiplexing saves pins, but it creates two practical problems: the firmware must refresh the matrix continuously, and the current peaks through the active row or column must stay inside the matrix and driver ratings.
This is why small LED matrix kits usually include more than the visible block. A review should identify the matrix block, socket or carrier PCB, headers, passive parts, and the display-driver IC before treating the kit as “just LEDs.” The driver owns the repetitive refresh and current-limited switching while the microcontroller sends compact display data.
The MAX7219/MAX7221 family is a common example. It sits between the MCU and the matrix: DIN receives serial data, CLK clocks bits in, LOAD or CS latches a command, and DOUT can pass data to another driver. On the display side, the DIG0 through DIG7 pins select rows or digits, while SEG A through SEG G and SEG DP drive the eight column or segment lines. V+ and GND power the chip, and the ISET resistor sets the peak segment current.
For a raw 8x8 LED matrix, leave decode mode off and write row or column bit patterns directly. The register addresses are part of the wiring evidence: 0x01 through 0x08 hold the eight digit or row data bytes, 0x09 controls decode mode, 0x0A controls intensity, 0x0B sets the scan limit, 0x0C leaves shutdown mode, and 0x0F enables or disables display test. A first proof can write a diagonal or single-row sweep, then record whether the image is rotated, mirrored, or missing rows.
#include <LedControl.h>
#define DIN_PIN 23
#define CLK_PIN 18
#define CS_PIN 5
LedControl matrix(DIN_PIN, CLK_PIN, CS_PIN, 1); // one MAX7219 device
void setup() {
matrix.shutdown(0, false); // leave shutdown mode
matrix.setIntensity(0, 4); // 0-15 brightness range
matrix.clearDisplay(0);
}
void loop() {
for (int row = 0; row < 8; row++) {
matrix.clearDisplay(0);
matrix.setRow(0, row, 1 << row); // diagonal orientation test
delay(150);
}
}The chip interface is small, but it is still a protocol. Each update is a 16-bit instruction: one address byte selects the target register and one data byte supplies the value. CLK advances each bit, DIN carries the bit value, and LOAD or CS latches the complete command. If the display is blank, check shutdown mode first, then confirm that the data, clock, and load pins match the library constructor.
Treat the display library as an adapter, not as magic. A library such as LedControl hides the bit shifting and latch timing, but the review still needs to name the processor-side pins, the number of chained devices, the matrix orientation, and the character table used by the application. A character library is usually just a set of eight-byte patterns: each byte represents one row or column of an 8x8 glyph. That makes the first message display a useful integration test because it proves both the wiring and the glyph orientation.
const byte smile[8] = {
B00111100,
B01000010,
B10100101,
B10000001,
B10100101,
B10011001,
B01000010,
B00111100
};
void drawGlyph(int device, const byte glyph[8]) {
for (int row = 0; row < 8; row++) {
matrix.setRow(device, row, glyph[row]);
}
}When several LED blocks are chained, DOUT from one driver feeds DIN on the next and the constructor’s device count changes. That is the main code difference between a one-block demo and a multi-block message board. Keep the physical order explicit: device 0 might be the block nearest the microcontroller or the farthest block, depending on how the modules are wired. A scrolling message, a dice face, or a small game animation should be treated as a final demo after the evidence path has already proved power, orientation, scan limit, intensity, and per-block addressing.
Keep the evidence close to the hardware. Record supply voltage, common ground, library version, DIN/CLK/CS pins, matrix orientation, current setting, and the known-good test pattern. If the first display appears scrambled, fix the row/column mapping or module orientation before adding animations; otherwise the software may hide a wiring error behind a pretty pattern.
Checkpoint: Pixel Chains and Matrices
You now know:
Once the output needs words, values, or menus instead of colored states, a display becomes the clearer actuator.
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27, 16, 2); // Address 0x27, 16 columns, 2 rows
void setup() {
lcd.init();
lcd.backlight();
lcd.setCursor(0, 0);
lcd.print("IoT System");
lcd.setCursor(0, 1);
lcd.print("Initializing...");
delay(2000);
}
void loop() {
// Display temperature
float temperature = 25.4;
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("Temperature:");
lcd.setCursor(0, 1);
lcd.print(temperature);
lcd.print(" C");
delay(2000);
// Display humidity
float humidity = 65.2;
lcd.clear();
lcd.setCursor(0, 0);
lcd.print("Humidity:");
lcd.setCursor(0, 1);
lcd.print(humidity);
lcd.print(" %");
delay(2000);
}OLED displays offer high contrast, low power consumption, and graphical capabilities.
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>
Adafruit_SSD1306 display(128, 64, &Wire, -1);
void setup() {
display.begin(SSD1306_SWITCHCAPVCC, 0x3C);
display.setTextColor(SSD1306_WHITE);
}
void loop() {
// Display sensor readings
display.clearDisplay();
display.setTextSize(2);
display.setCursor(0, 0);
display.print("IoT Data");
display.setTextSize(1);
display.setCursor(0, 20);
display.print("Temp: 25.4 C");
display.setCursor(0, 35);
display.print("Humid: 65.2 %");
display.display();
delay(2000);
// Draw a progress bar
for (int pct = 0; pct <= 100; pct += 2) {
display.clearDisplay();
display.setCursor(0, 10);
display.print("Loading...");
display.drawRect(10, 30, 108, 10, SSD1306_WHITE);
display.fillRect(12, 32, pct, 6, SSD1306_WHITE);
display.display();
delay(40);
}
}You now know:
Visual feedback can show state quietly. The next section covers the output that interrupts attention.
Passive buzzers can play different frequencies/tones.
Calculate frequencies for musical notes and explore the relationship between pitch and frequency:
Common Notes for Buzzers:
#define BUZZER_PIN 25
// Musical notes (frequencies in Hz)
#define NOTE_C4 262
#define NOTE_D4 294
#define NOTE_E4 330
#define NOTE_F4 349
#define NOTE_G4 392
#define NOTE_A4 440
#define NOTE_B4 494
#define NOTE_C5 523
void setup() {
pinMode(BUZZER_PIN, OUTPUT);
}
void loop() {
playMelody();
delay(2000);
playAlarm();
delay(2000);
playNotification();
delay(5000);
}
void playMelody() {
int melody[] = {NOTE_C4, NOTE_E4, NOTE_G4, NOTE_C5};
int durations[] = {250, 250, 250, 500};
for (int i = 0; i < 4; i++) {
tone(BUZZER_PIN, melody[i], durations[i]);
delay(durations[i] * 1.3); // Pause between notes
}
noTone(BUZZER_PIN);
}
void playAlarm() {
for (int i = 0; i < 5; i++) {
tone(BUZZER_PIN, 1000, 200);
delay(250);
tone(BUZZER_PIN, 500, 200);
delay(250);
}
noTone(BUZZER_PIN);
}
void playNotification() {
tone(BUZZER_PIN, NOTE_A4, 100);
delay(150);
tone(BUZZER_PIN, NOTE_C5, 200);
delay(250);
noTone(BUZZER_PIN);
}Active buzzers have built-in oscillators - just supply power.
#define BUZZER_PIN 25
void setup() {
pinMode(BUZZER_PIN, OUTPUT);
}
void beep(int count, int onTime, int offTime) {
for (int i = 0; i < count; i++) {
digitalWrite(BUZZER_PIN, HIGH);
delay(onTime);
digitalWrite(BUZZER_PIN, LOW);
delay(offTime);
}
}
void loop() {
// Single beep
beep(1, 100, 0);
delay(2000);
// Double beep
beep(2, 100, 100);
delay(2000);
// Alarm pattern
beep(5, 50, 50);
delay(2000);
}Buzzers add urgency, but they also add fatigue. The selection guide that follows treats sound as one channel in a larger feedback design, not as the default answer for every event.
| Display | Power | Contrast | Update Rate | Best Use Case |
|---|---|---|---|---|
| 16x2 LCD | 20-100mA | Medium | Fast | Indoor, mains powered |
| OLED | 10-50mA | High | Fast | Battery, frequent updates |
| E-paper | 0.001mA | Highest | Slow (1s) | Battery, infrequent updates |
| TFT LCD | 100-300mA | Medium | Very fast | Mains powered, graphics |
Scenario: A team is designing bedside monitors for a clinical ward. Each monitor tracks several patient readings and must draw staff attention to urgent conditions while avoiding constant, low-value beeping.
Constraints:
| Requirement | Specification | Why |
|---|---|---|
| Critical alarm response | Immediate local awareness | Urgent states should not depend on someone watching the display |
| Ambient noise level | Variable, with conversation and equipment noise | Audio must be noticeable without being constant |
| Night shift visibility | Low-light conditions | Visual cues essential |
| False alarm handling | Suppress nuisance alerts and escalate confirmed problems | Prevents alarm fatigue |
| Power budget | Mains-powered (not a constraint) | Hospital monitors plugged in |
Actuator Selection Analysis:
| Feedback Channel | Component Selected | Rationale |
|---|---|---|
| Critical alarm (audio) | Passive buzzer or speaker with distinct tone patterns | Variable frequency can distinguish alarm classes |
| Critical alarm (visual) | Red strobe or high-visibility LED pattern | Visible when staff are not looking at the screen |
| Warning (audio) | Shorter, quieter pulse pattern | Distinct from critical alarms and less fatiguing |
| Warning (visual) | Amber LED steady glow | Visible but non-urgent; amber = caution |
| Normal status | Green LED steady | “All OK” at a glance; no audio (reduces noise floor) |
| Detailed readings | OLED or LCD display sized for the enclosure | High contrast and readable labels for local inspection |
| Nurse station | Larger graphical display | Multiple patients and alert states can be compared quickly |
Why NOT these alternatives?
Design Decision: Audio Pattern Differentiation
The system uses distinct alarm patterns so staff can identify urgency without first reading the screen:
| Alarm Type | Audio Pattern | Frequency | Priority |
|---|---|---|---|
| Critical physiological alarm | Repeating high-priority pattern | High pitch band | Highest |
| Urgent measurement alarm | Descending or alternating pattern | Mid/high pitch band | High |
| Device or sensor problem | Short repeated pulses | Mid pitch band | Medium |
| Low battery / sensor off | Occasional single pulse | Lower pitch band | Low |
Resulting design: Critical alarms use both a visual channel and an audio channel, warnings use lower-intensity patterns, and normal operation stays visual-only. That separation keeps urgent states noticeable while reducing unnecessary sound.
Checkpoint: Alert Selection
You now know:
Visual and audio actuators provide essential user feedback in IoT systems. LEDs range from simple indicators to addressable strips capable of complex animations. Displays should be selected based on power budget (e-paper for battery, OLED for moderate updates, TFT for rich graphics). Passive buzzers offer flexible tone generation for alerts and melodies, while active buzzers provide simple on/off beeping. Always consider power consumption, as displays and LED strips can be the largest power consumers in a battery-powered IoT device.
“Time for the Output Show!” announced Lila the LED, glowing all the colors of the rainbow. “We’re the actuators that you can SEE and HEAR!”
“Let me go first!” Lila said excitedly. She started dim, then slowly grew brighter and brighter. “Max controls my brightness with PWM – the same trick he uses for motors! But instead of spinning faster, I glow brighter!”
Then a whole strip of her NeoPixel friends lit up, each one a different color. “Meet my addressable friends! Even though there are 30 of us, Max only needs ONE wire to talk to all of us. The first pixel reads its color instruction, then passes the rest of the message down the chain – like a game of telephone, but it actually works perfectly!”
Next, Buzzy the Buzzer cleared his throat. “BEEP BOOP BEEEEP!” He played a little melody. “I’m a passive buzzer, which means Max can make me play ANY note by changing how fast he vibrates me. Higher frequency = higher pitch! I can even play songs!”
“And I’m the screen!” said OLED Olivia, displaying a smiley face. “I can show Sammy’s temperature readings, draw pictures, and even make progress bars. I use tiny organic light-emitting dots – each pixel makes its own light, so I’m super bright and clear!”
“We all work together,” said Sammy the Sensor. “I measure the temperature, Max decides what to do, and then Lila shows green for ‘all good,’ Olivia displays the number, and Buzzy beeps if it gets too hot. Input to output – that’s the IoT loop!”
Bella the Battery whispered, “Just remember, all those pretty lights use MY energy. Turn them off when nobody’s looking!”
LEDs, displays, and buzzers are simple only at the user interface. Electrically, each one still has a load path and a control signal. A small status LED shows the pattern: if a 3.3 V GPIO drives a red LED with about 2.0 V forward drop at 10 mA, the resistor must drop 1.3 V, so R = (3.3 - 2.0) / 0.010 = 130 ohms. Choosing 150 ohms gives I = 1.3 / 150 = 0.0087 A, or 8.7 mA. The resistor dissipates 1.3 V x 0.0087 A = 0.011 W, so a small signal resistor has margin. At 25% PWM duty cycle, the average LED current is about 8.7 mA x 0.25 = 2.2 mA.
The design decision is not only electrical. Feedback actuators differ in noticeability, power, and information density. A single green LED is excellent for a healthy status, but poor for a fault that must be noticed across a room. A display can show numbers and labels, but only helps when someone is looking at it. A buzzer interrupts attention, but repeated audio becomes annoying and may be masked by the environment. Strong products combine channels: quiet visual status for normal operation, stronger visual patterns for warnings, and audio only when the state needs immediate attention.
Displays need the same budget discipline. If a small OLED draws 20 mA from a 3.3 V rail while lit, the display load is 3.3 V x 0.020 A = 0.066 W. Left on for 24 hours, that is 0.066 W x 24 h = 1.58 Wh before regulator losses. On a small battery device, that can dominate the energy budget. If the value changes only occasionally, e-paper is often a better human interface because it can keep an image visible between refreshes without continuous display power.
Buzzers split into two kinds that are often confused. An active buzzer has an internal oscillator and produces one fixed tone when powered. A passive piezo or magnetic buzzer needs the controller to supply an audio-frequency waveform. A 2 kHz passive-buzzer alert has a period of 1 / 2000 = 0.0005 s, or 500 microseconds; a 50% square wave is high for about 250 microseconds and low for about 250 microseconds. A lower 500 Hz warning tone has a period of 1 / 500 = 0.002 s, or 2 ms. The controller changes pitch by changing the period, not by changing the supply voltage.
Addressable LEDs such as WS2812/NeoPixel parts add a different kind of timing constraint. Each pixel contains a driver chip, reads the first 24 bits as its green, red, and blue values, and forwards the rest downstream. There is no clock line; each bit is encoded by pulse width and lasts roughly 1.25 microseconds. A 30-pixel strip therefore needs 30 pixels x 24 bits = 720 bits, or 720 x 1.25 = 900 microseconds, plus the reset interval. An interrupt that pauses the GPIO waveform halfway through a bit can corrupt the data seen by every later pixel.
That timing issue is separate from the power issue. The same 30-pixel strip at full white can draw 30 x 60 mA = 1.8 A, which is 5 V x 1.8 A = 9 W. A microcontroller pin can generate the data waveform, but the 5 V supply and ground return must carry the power. Random flicker can come from data timing or from supply droop, so debug in order: limit brightness, confirm common ground, check the 5 V rail under load, then inspect whether the data driver can keep sub-microsecond timing without interruption.
Visual and audio actuators transform digital data into human-perceivable feedback. Key concepts:
LED Control:
Addressable LED Strips:
Displays:
Buzzers:
Design Considerations:
An LED connected directly from VCC to GPIO (or directly to a supply) has no resistance to limit current. LED forward voltage (1.8-3.5 V) is much less than supply voltage (3.3-5 V). The excess voltage forces very high current through the LED, burning it out within seconds. Always calculate and install a current limiting resistor: R = (Vsupply - Vf) / If_desired.
A passive buzzer requires an oscillating signal (PWM at audio frequency) to produce sound — it is simply a piezo element that vibrates at the applied frequency. Applying a DC HIGH from a GPIO pin to a passive buzzer produces no sound (or a brief click as it deflects). Use analogWrite() or tone() with an audio-range frequency (1 kHz - 5 kHz) for audible output from passive buzzers.
WS2812B addressable LED strips draw up to 60 mA per RGB LED at full white brightness. A strip of 30 LEDs draws 1.8 A. This exceeds GPIO current limits by 100x and exceeds typical USB power adapter capacity. Always power LED strips from a dedicated 5 V power supply rated for the full strip current, with a shared common ground to the MCU.
Active buzzers contain an internal oscillator and produce a fixed tone when voltage is applied (just connect VCC and GND). Passive buzzers require an external oscillating signal. They look identical externally and share the same package styles. Testing with a DC supply: active buzzers beep immediately; passive buzzers are silent. Apply the wrong driving method to the wrong buzzer type and you will get no sound.
Now that you understand visual and audio actuators, explore related actuator types and deeper control techniques.
| Next Topic | Description |
|---|---|
| PWM Control | Deeper dive into duty cycle calculations and waveform generation |
| DC Motors | Speed and direction control using H-bridge drivers and PWM |
| Servo Motors | Precise angular positioning with pulse-width control |
| Actuator Safety | Flyback protection, current limiting, and thermal management |
| Actuator Classifications | Survey of all actuator types and selection criteria |