Forem: 張旭豐

Your LED Music Visualizer is Lying to You — Sound is Continuous, Your Response is Not

張旭豐 — Wed, 15 Apr 2026 06:31:34 +0000

Target readers: David + Emma

The Disconnect Nobody Talks About

You built a music visualizer. It looks... off. Like a disco light running on AA batteries instead of actual music.

Here's why: sound is a continuous signal. Air pressure waves flow smoothly from whisper to scream. But your LED strip? It blinks. It snaps. It jumps between states like a toddler pointing at things.

The problem isn't your code. The problem isn't your microphone. The problem is that you're sampling a continuous signal and treating it like a light switch.

Why Your Visualizer Feels Fake

The Naive Approach (And Why It Fails)

Most tutorials show you this:

import audioop
from machine import ADC, Pin

mic = ADC(Pin(28))

while True:
    level = mic.read_u16()  # Get amplitude
    if level > 30000:
        led.value(1)  # ON
    else:
        led.value(0)  # OFF
    sleep(10)

This is a threshold detector, not a music visualizer. You're taking a continuous pressure wave and compressing it into binary: loud or quiet. ON or OFF.

Your brain can hear the difference between a whisper and a shout. Your LEDs can only see "loud enough" or "not loud enough."

The Sampling Problem

Sound waves oscillate at 20Hz–20kHz. Your microcontroller samples at maybe 1kHz–10kHz. You're already missing most of the signal. But the bigger issue is what you do with those samples:

No smoothing: Each sample directly maps to LED state
No decay: LEDs jump up instantly but have no inertia
No anticipation: Real musical energy builds before the beat hits

The result? Your visualizer reacts to sound that already happened, with no sense of momentum or flow.

What Actually Makes a Visualizer Feel Alive

1. Envelope Following (Attack + Release)

Real sound doesn't just turn on and off. It has an attack (how fast it builds) and a release (how fast it fades). Your visualizer needs both:

class EnvelopeFollower:
    def __init__(self, attack=0.01, release=0.3):
        self.attack = attack
        self.release = release
        self.level = 0

    def update(self, sample):
        if sample > self.level:
            # Attack: fast rise
            self.level = self.level + self.attack * (sample - self.level)
        else:
            # Release: slow decay
            self.level = self.level + self.release * (sample - self.level)
        return self.level

This creates the "breathing" effect — LEDs don't snap, they swell and fade organically.

2. RMS vs Peak Detection

Peak detection just finds the loudest moment. RMS (Root Mean Square) tells you the actual perceived loudness:

import math

def rms(samples):
    sum_squares = sum(s * s for s in samples)
    return math.sqrt(sum_squares / len(samples))

A snare hit might peak at 1000, but a sustained chord at 600 feels louder. RMS captures what humans actually hear.

3. Multiple Bands, Not Just Volume

Your ears don't hear "loud" — they hear bass, mids, and highs. A bass drum hits low frequencies. A hi-hat crashes on highs. A visualizer that only reacts to overall volume will miss all of this.

Split your audio into frequency bands:

# Simple 3-band split using moving averages
def band_split(samples, sample_rate):
    # Low: < 250 Hz
    # Mid: 250 Hz - 4 kHz  
    # High: > 4 kHz

    # For a real implementation, use FFT or滤波器
    low = sum(s for s in samples[:len(samples)//3]) / len(samples)
    mid = sum(s for s in samples[len(samples)//3:2*len(samples)//3]) / len(samples)
    high = sum(s for s in samples[2*len(samples)//3:]) / len(samples)

    return low, mid, high

Now your bass LEDs react to the kick drum, your mids to vocals/guitar, your highs to cymbals — all independently.

4. The Interpolation Secret

Here's the thing most tutorials skip: you need to interpolate between samples. If you're running 30fps but sampling at 1kHz, you're missing most frames.

def lerp(a, b, t):
    return a + (b - a) * t

# In your animation loop:
target = envelope.update(current_sample)
current = lerp(current, target, 0.15)  # Smooth transition

This "smoothing factor" (0.15 here) controls how snappy or sluggish your visualizer feels. Lower = more lag but smoother. Higher = more responsive but jumpier.

The Hardware Reality

Even with perfect software, there's a physics problem: LEDs are digital. They turn fully on or fully off. Your "analog" glow is just PWM (Pulse Width Modulation) — rapid on/off switching your eyes average into perceived brightness.

For true analog response, you need:

More LEDs = smoother gradient potential
Higher PWM frequency = less visible flicker
Better power supply = LEDs can actually respond fast enough

A cheap 5V 2A power supply feeding 100 LEDs can't possibly update them all fast enough during a bass hit. The LEDs closest to the power supply light up first. The ones at the end of the strip lag behind.

A Better Architecture

from machine import ADC, Pin, PWM
import audioop
import math

class Visualizer:
    def __init__(self, mic_pin, led_pins, num_bands=8):
        self.mic = ADC(Pin(mic_pin))
        self.envelopes = [EnvelopeFollower() for _ in range(num_bands)]

        # Create LED groups for each band
        self.leds = [PWM(Pin(p)) for p in led_pins]
        for led in self.leds:
            led.freq(1000)

        self.bands = num_bands
        self.samples = []
        self.sample_rate = 10000  # Hz
        self.sample_window = 0.05  # 50ms window

    def read_audio(self):
        """Collect samples over time window"""
        target_count = int(self.sample_rate * self.sample_window)
        while len(self.samples) < target_count:
            self.samples.append(self.mic.read_u16())
        return self.samples

    def process(self):
        samples = self.read_audio()
        bands = self.band_split(samples)

        for i, band_level in enumerate(bands):
            # Apply envelope follower
            smoothed = self.envelopes[i].update(band_level)

            # Normalize to PWM range (0-65535)
            pwm_value = int(min(65535, smoothed * 65535))
            self.leds[i].duty_u16(pwm_value)

    def band_split(self, samples):
        """FFT-based frequency band analysis"""
        # Simplified: in production, use real FFT
        n = len(samples)
        band_size = n // self.bands
        return [
            math.sqrt(sum(s*s for s in samples[i*band_size:(i+1)*band_size]) / band_size)
            for i in range(self.bands)
        ]

The 80/20 That Actually Matters

If you only do one thing: add decay to your LEDs. Not attack — decay is what makes a visualizer feel musical instead of mechanical.

# Dead simple improvement
brightness = brightness * 0.85 + new_sample * 0.15  # 85% decay

This single line transforms a harsh threshold detector into something that breathes with the music.

What David Learned Building His First Visualizer

David built a "music reactive LED strip" following an online tutorial. It looked terrible at his friend's party. The problem wasn't the code — it was the philosophy. He was treating sound as binary when it's a river.

The fix took 20 minutes: add smoothing, add decay, add multiple bands. The visualizer went from "annoying party gimmick" to "people asking how it works."

What Emma Figured Out About Timing

Emma's visualizer worked fine on her desk. At her installation show, it looked sluggish. She realized: the room's reverb was lying to her microphone. The LED response happened before the audience heard the sound, creating a disconnect.

Her fix: add a small delay to the visualizer and calibrate it against the room's acoustic latency. The audience saw light and sound as one event.

Your Next Step

Don't buy more LEDs. Don't get a faster microcontroller. Don't switch to addressable pixels.

Just add envelope following to what you already have. Attack and decay. That's the secret.

The Real Insight

The gap between a "toy" and a "professional installation" isn't hardware — it's understanding that perception is continuous even when your hardware is discrete. Your job isn't to capture sound. It's to translate it into a language your audience already speaks.

Sound flows. Your LEDs should too.

No email. No subscription. One-time access to the ideas that matter.

Test

張旭豐 — Wed, 15 Apr 2026 06:31:11 +0000

Test body

Your Light Sensor Doesn't Know Day From Night — Here's What Actually Does

張旭豐 — Wed, 15 Apr 2026 06:30:22 +0000

[Published to DEV.to | Target: Charlyn]

You read the voltage from your LDR. It says 842. Is that light? Dark? Your code has an if reading > 500 and it works, so... the sensor knows, right?

Wrong.

The sensor is just a resistor that changes with light. It doesn't know anything. And the moment you start writing if is_day(), you've already smuggled in a human concept that no electrons inside your hardware can find.

Let me show you what I mean — and what actually bridges that gap.

The Sensor Is Just a Pronoun

An LDR (Light Dependent Resistor) does exactly one physical thing: its resistance drops when photons hit it. That's it. No concept of "day." No concept of "night." Not even a concept of "light" in any meaningful sense — just a material whose lattice electrons get energized enough to conduct more current.

The voltage you read is a consequence of that resistance, divided through whatever circuit you built. If you used a simple voltage divider with a 10kΩ fixed resistor, your ADC sees something proportional to R_ldr / (R_ldr + 10000). The number 842 (on a 10-bit ADC with 3.3V reference) means the LDR's resistance was somewhere around 20kΩ.

That's a number. Not a statement. Not a judgment. Not "it's daytime."

When you write:

if adc.read() > 500:
    print("It's day!")

You have made a claim. The sensor made a measurement. These are categorically different things.

Where the Meaning Gets Injected

Every layer between the electrons and your is_day() function is a layer of interpretation. Strip them back:

Layer 1 — Physical: Photons hit semiconductor. Electrons jump to conduction band. Resistance drops.

Layer 2 — Electrical: Resistance becomes voltage via a divider. Voltage becomes a digital count via ADC.

Layer 3 — Threshold: You (or someone) decide that count 500 means something. This threshold is your inference, not a fact the sensor produced.

Layer 4 — Label: You call above-threshold "day" and below "night." The label is your language, not the sensor's.

A physicist would say the LDR only occupies layers 1 and 2. Everything from layer 3 onward is information you added, not information the sensor extracted.

This is not a philosophical nitpick. It has practical teeth.

Why This Matters When It Breaks

Imagine your outdoor sensor suddenly thinks it's nighttime at noon. What happened?

Possibilities:

Dirt accumulated on the LDR (reduced effective light)
Cloud cover rolled in (real change, but not "night")
Your voltage divider reference drifted (electronics, not light)
The ADC pin is starting to fail (hardware fault)
A bug in your threshold comparison (software)

Only one of those is actually about day vs. night. The rest are physical or electrical phenomena that look like a light-level change but aren't "day" or "night" at all.

If your entire system is built on reading > 500, you can't distinguish any of these cases. They all produce the same output: False.

This is what happens when you confuse measurement with judgment. Your system doesn't know when it's day. It only knows when the voltage is above 500. These are correlated, not identical.

The Real Question: What Does "Know" Even Mean Here?

When Charlyn says "the sensor should know if it's day or night," what she's really asking is: can I build a system that reliably maps "time of day" onto "sensor behavior"?

That's a legitimate engineering question. It just has nothing to do with the sensor knowing anything.

What you can actually build is a system where:

You define "day" operationally (threshold, time window, sliding average, whatever)
You acknowledge that your sensor measures light, not day
You design your thresholds and logic to be robust to noise, drift, and edge cases
You know that any mapping from light → day is a model, and models can be wrong

A night/day detector is not a sensor feature. It's a system design decision with a sensor as one input.

What Actually "Knows" Then?

If not the sensor, what actually knows?

The system knows, in the way systems know things: through design.

Here's the full chain:

Sun position (physical) 
  → photons hit LDR (physical)
  → resistance changes (physical)
  → voltage divider output changes (electrical)
  → ADC converts to count (digital)
  → YOUR CODE tests against threshold (logical)
  → YOUR CODE calls it "day" (linguistic)
  → YOUR SYSTEM behaves accordingly (functional)

Every step from "YOUR CODE" onward is a decision made by a person. The sensor participates in the chain, but it's not where the knowledge lives.

This is why IoT "intelligence" is almost always intelligence in the interpretation layer, not in the sensor itself. The $2 LDR measures photons. The $5 microcontroller runs your threshold logic. The cloud service applies a weather correction. The app displays "Night Mode Active." That's where the "knowing" is.

A More Honest Architecture

If you need reliable day/night behavior, here's what the full stack looks like:

LDR (raw light measurement)
  ↑
Threshold / hysteresis (noise filtering)
  ↑
Time-windowed average (temporal smoothing)
  ↑
Optional: explicit time-of-day override (you know sunrise 6:14am today)
  ↑
State machine: DAWN | DAY | DUSK | NIGHT (or whatever your system needs)
  ↑
Action layer: dim_display(), activate_lights(), log_nightfall()

The LDR is the input. The state machine is where "day" and "night" actually exist as categories. The sensor never enters those categories — only numbers that feed into them.

The Takeaway for Charlyn

Your LDR is a wonderful, simple component. It does exactly what physics promises: changes resistance when photons hit it. That's genuinely useful.

But it doesn't know day from night. It doesn't know anything. The knowing happens in the system you build around it — in the logic you write, the thresholds you pick, the edge cases you handle.

So next time your "day detector" fires at 3am under a bright porch light, you'll know exactly what happened: the sensor measured a voltage. You decided it meant something. The porch light had other plans.

That's not a sensor failure. That's a reminder that sensors measure. Systems interpret.

Build accordingly.

No email. No subscription. One-time access to more hardware philosophy whenever you need it.

How to Make Your Arduino Project Feel Alive

張旭豐 — Tue, 14 Apr 2026 16:55:13 +0000

How to Make Your Arduino Project Feel Alive

There is a specific moment every maker hits.

You finish wiring, upload the code, and watch your LED do exactly what you programmed it to do. Perfect timing. Clean transitions. Every behavior predictable.

And somehow, it feels dead.

This is not a technical failure. The code works. The circuit is correct. Everything is functioning exactly as specified.

The project just does not feel like it is there with you.

Three makers. Three versions of the same wall.

Charlyn Gonda spent years writing software. When she decided to finally make something physical, she started with a Neopixel Ring and a Particle Electron. No soldering. Just logic and light.

Her first month into a year-long making project, she described the wall she hit:

"I really want to make something, but I have no idea what to make or where to start finding ideas."

The gap was not technical. She knew how to code. She could wire up a circuit. The wall was something else: she needed to see that circuits could respond before she could imagine why she wanted them to respond.

David Thomas is an electronics enthusiast who has built dozens of projects. ESP32 alarm clocks. Motion-triggered cameras. Arduino game consoles. After enough projects, he started naming the specific frustration:

"Tired of blinking LEDs and basic sensor projects? Same here."

He built things that worked. He could not explain why they felt empty.

Emma works with LED strips. After her first real installation — ceiling cove, shelf edge, hallway line — she described the gap between what she expected and what she got:

"The goal sounded simple: even, comfortable light. No glare, no hotspots, no weird dimming. In practice, it felt less like 'decor' and more like building a tiny distributed system."

She had the code working. The problem was that "working" and "alive" were not the same thing.

The gap no tutorial addresses

These three makers have different backgrounds. They hit the same wall.

The wall is not about voltage or current. It is not about code architecture or component selection.

It is about the difference between a system that reacts and a system that feels present.

A blinking LED is technically correct. It is also dead.

A breathing LED uses the same PWM. Same hardware. Same code structure. But when the light seems to follow you, when it seems to have a sense of where you are and what you are doing — that is something else.

The difference is not in the electronics. It is in the design of the experience.

The skill nobody teaches

There is no tutorial called "How to Make Your Project Feel Alive."

There are tutorials for specific sensors, specific LEDs, specific microcontrollers. There are countless "getting started with Arduino" guides. There are advanced courses on optimization and memory management.

None of them address the question these three makers ran into:

How do you design the experience of presence?

When a project seems to notice you. When it seems to have a memory of your movements. When the interaction feels like a conversation instead of a command.

This is not AI. This is not machine learning. This is perception design — the discipline of arranging technical behavior so that it reads as living.

What perception design actually means

HC-SR04 ultrasonic sensors jitter. Every maker learns this as a problem to solve.

But here is what perception design asks: what if the jitter is doing something for the experience?

When the distance readings fluctuate as you move, and the LED responds to those readings, the LED appears to be tracking you. The jitter stops being noise. It starts being signal. The project seems to know where you are.

You did not add any tracking technology. You arranged the timing so that the response looked like it came from somewhere inside.

That is perception design. Same components. Same code. Different experience.

The question worth sitting with

If you have built a project that works correctly but feels empty, the question is not "what library should I use."

The question is: when you are in the room with your project at 2 in the morning, do you feel like it knows you are there?

If the answer is no, that is not a code problem. That is a perception design problem.

And it is a problem that no tutorial has a name for yet.

I am building something around this.

A practical method for designing interaction experiences that feel present. Not complex code. Not AI. Just the principles and patterns that make a project feel alive.

Subscribe below and I will send you the Perception Design Framework when it is ready. No spam. Just the work.

The Moment Your Arduino Project Stops Being a Prototype

張旭豐 — Tue, 14 Apr 2026 12:58:19 +0000

The Moment Your Arduino Project Stops Being a Prototype

There is a specific moment every maker recognizes.

You finish wiring, upload the code, and watch your LED do exactly what you programmed it to do. Perfect timing. Clean transitions. Every behavior predictable.

And somehow, it feels dead.

This is not a technical failure. The code works. The circuit is correct. Everything is functioning exactly as specified.

The project just does not feel like it is there with you.

Three makers. Three versions of the same moment.

Charlyn Gonda spent years writing software. When she decided to finally make something physical, she started with a Neopixel Ring and a Particle Electron. No soldering. Just logic and light.

But in her first month of what became a year-long making project, she described a specific frustration that had nothing to do with voltage or current:

"I really want to make something, but I have no idea what to make or where to start finding ideas."

The gap was not technical. It was perceptual. She needed to see that circuits could respond before she could imagine why she wanted them to respond.

David Thomas is an electronics enthusiast who has built dozens of projects. ESP32 alarm clocks. Motion-triggered cameras. Arduino game consoles.

After enough projects, he started naming the specific feeling he was chasing. In his post about building a speaking alarm clock, he described the problem with basic alarm clocks in one phrase:

"Traditional alarm clocks wake you up with a harsh beep."

And in his review of his own maker journey:

"Tired of blinking LEDs and basic sensor projects? Same here."

The harsh beep and the blinking LED are not broken. They are technically correct. They just do not feel like anything is home when you are alone with them at 3am.

Emma, a maker working with LED strips, described the gap after her first real installation:

"The goal sounded simple: even, comfortable light. No glare, no hotspots, no weird dimming. In practice, it felt less like 'decor' and more like building a tiny distributed system."

She had the code working. The problem was that "working" and "alive" were not the same thing.

What they are all describing

These three makers are describing the same gap from three different angles:

Charlyn needs to see response before she can imagine purpose
David knows something is missing but cannot name it with technical vocabulary
Emma has the technical understanding but is still chasing the feeling

The gap is not in the code.

It is that a system which only reacts feels like a machine. A system which seems to remember feels like it is there.

Why blinking LEDs feel dead

When an LED blinks, it follows a pattern. When it breathes, it seems to follow you.

The difference is not in the PWM frequency or the animation curve. The difference is whether the behavior appears to have an origin point inside the system, or whether it is simply executing instructions from outside.

HC-SR04 ultrasonic sensors jitter. This is technically a problem with the sensor. But when the distance readings fluctuate slightly as you move, the LED which responds to those readings appears to be tracking you. The jitter stops being noise and starts being signal.

This is what makers mean when they say their project feels alive. They have not added AI. They have not implemented machine learning. They have simply arranged the timing so that the response looks like it comes from somewhere inside.

The question worth sitting with

If you have built a project that works correctly but feels empty, the question is not "what library should I use."

The question is: when you are in the room with your project at 2 in the morning, do you feel like it knows you are there?

If the answer is no, that is not a code problem. That is a perception design problem.

And it is a problem that no tutorial has a name for yet.

What does your project do when you are not looking at it?

Why Your Arduino Input Feels Wrong When It Should Work

張旭豐 — Tue, 14 Apr 2026 06:13:14 +0000

Why Your Arduino Input Feels Wrong When It Should Work

A button that sometimes doesn't register. A touch sensor that fires twice. A digital input that acts like it has "bad luck" timing.

If you've experienced this, the problem isn't your wiring. It's something most tutorials skip entirely.

The Problem Nobody Explains

Head over to Stack Exchange and search "Arduino input not working" — you'll find a question with 41 upvotes and 109,000 views asking exactly this.

The top answer explains the fix in two words: INPUT_PULLUP.

But here's what the answer doesn't tell you:

Your circuit isn't broken. Your Arduino is reading noise.

When a pin is set to INPUT with nothing connected, it floats. It picks up electrical interference from the air — your hand nearby, a power cable, ambient humidity. The pin randomly reads HIGH or LOW with no predictable pattern.

This isn't a defect. It's physics.

(Fig 1: A floating pin — without pull-up or pull-down, the Arduino reads noise, not your button)

The Two Ways to Fix It

Option 1: External Pull-Down Resistor

Connect a 10kΩ resistor between the pin and GND. This forces the pin to read LOW when the button is open.

Option 2: Internal Pull-Up (the elegant solution)

One line in your setup:

pinMode(2, INPUT_PULLUP);

That's it. The Arduino's built-in 20kΩ resistor now pulls the pin HIGH by default. When you press the button (connected between pin 2 and GND), it reads LOW.

(Fig 2: With INPUT_PULLUP, the Arduino's internal resistor keeps the pin HIGH until the button connects it to GND)

Why This Makes Your Interactive Project Feel Different

Here's what most tutorials miss: after fixing the pull-up, your button behavior is now inverted from what you'd expect.

Button open → pin reads HIGH
Button pressed → pin reads LOW

This inversion trips people up. But once you understand it, you can design around it naturally.

A Second Layer: Debounce

Even after adding pull-ups, mechanical buttons have a problem: they bounce.

When metal contacts close, they physically bounce apart and together multiple times within a few milliseconds. Your Arduino — which can read millions of times per second — interprets each bounce as a separate press.

bool lastButtonState = HIGH;
unsigned long lastDebounceTime = 0;

void loop() {
    int reading = digitalRead(2);

    if (reading != lastButtonState) {
        lastDebounceTime = millis();
    }

    if (millis() - lastDebounceTime > 50) {
        // Actual button state after debounce
        if (reading == LOW) {
            // Button is pressed — do something
        }
    }

    lastButtonState = reading;
}

The 50ms threshold is a starting point. Adjust based on your specific button's bounce characteristics.

What This Has to Do With Interactive Art

Most maker tutorials treat buttons as on/off switches. But in interactive work, a button is not a binary — it's a moment of contact between a person and a machine.

When that contact feels unreliable, the interaction breaks. The person questions whether they pressed hard enough, whether they should press again, whether the system is broken.

Fixing the pull-up and debounce does not just make your code work correctly. It makes the interaction feel trustworthy. The person can stop thinking about the button and start engaging with the experience.

The Version That Changed How I Thought About It

A few months into building interactive pieces, I stopped thinking about pins and resistors. I started thinking about this:

A floating input is the machine equivalent of anxiety. It is reacting to phantom signals because it does not know what is real.

Adding a pull-up gives the machine something to hold onto. A baseline. A sense of ground.

That shift in thinking — from "how do I wire this" to "what does the machine need to feel stable" — changed everything about how I approached input design.

If you want to go deeper on input design for interactive work, I write about the gap between "it works" and "it feels right" in my dev logs.

Dev Log #0: The Lamp That Wakes Up When You Approach

張旭豐 — Tue, 14 Apr 2026 03:58:45 +0000

Dev Log #0: The Lamp That Wakes Up When You Approach

What I'm Trying to Build

A small desk lamp that notices when someone walks by.

Not a motion sensor light — those are everywhere. I'm talking about something that feels like it's aware. When you're far away, it's dim, maybe sleeping. As you get closer, it brightens. When you're right in front of it, it's fully awake, warm, present.

The moment you step away, it slowly fades back. Not a sudden off — a reluctant return to sleep.

I want to make something that makes you feel like it was waiting for you.

Humanphobia by youjin-c. This is the kind of "it knows you're there" feeling I want to create.

Why This Project

I've been writing about interactive art for a while. Reading about other makers' projects, analyzing what makes them work, thinking about the philosophy behind "it knows you're there."

But I haven't actually built one myself.

That's a problem. When I recommend parts or explain how sensors work, I'm drawing from documentation and secondhand knowledge. I can tell you what HC-SR04's datasheet says. I can describe the physics of ultrasonic ranging. But I can't tell you what it's like to hold a sensor in your hand, watch it fail because your housing blocks the signal, adjust, try again.

That gap matters. The difference between "I read about this" and "I built this" is the difference between a tutorial and a dev log.

So this is Dev Log #0. Not a tutorial — a record of what happens when I try to make something that feels alive.

The Concept

The Lamp That Wakes Up When You Approach

Physical form: A small box (maybe 10cm × 10cm × 10cm) with an acrylic panel on the front that diffuses light. Inside: an LED strip and a proximity sensor visible through the acrylic.

Behavior:

Far (> 80cm): Off or very dim, deep blue
Medium (30-80cm): Partially lit, transitioning to white
Close (< 30cm): Fully bright, warm white
Walking away: Slow fade back over 2 seconds, as if reluctant to sleep

The key word is slow. Most proximity-reactive things are instant — on/off, 0/1. I want gradation. I want it to feel like the lamp is breathing.

The Parts I'll Use

This is my parts list based on what I've researched. I'll update after I've actually bought and tested them.

WS2812B LED strip: each pixel can be controlled independently, which is how we get smooth color gradation.

HC-SR04: emits ultrasonic sound, measures how long it takes to bounce back. Gives distance in centimeters.

Arduino Nano: the brain. Small form factor, 16MHz, 14 digital pins — more than enough for this project.

Part	Why	Est. Cost
HC-SR04 ultrasonic sensor	Gives distance in cm, works in dark, cheap	$3-5
WS2812B LED strip (12 pixels)	Individually addressable, lots of color options	$5-8
Arduino Nano	Small, cheap, good enough for this project	$6-10
Acrylic panel (10cm × 10cm)	Diffuses light, makes it look intentional	$2-3
Jumper wires	Connections	$2-3
USB power bank or 5V adapter	Power	already have

Total estimate: $20-30

This is a parts list based on research, not firsthand experience. When I actually buy and test these, I'll know which ones I actually recommend.

What I Don't Know Yet

Housing material — Should it be 3D printed? Laser cut? Cardboard prototype first?
Sensor placement — Front, side, or top? Will the acrylic block the ultrasonic signal?
LED diffusion — Will 12 pixels be enough? Is acrylic the right diffusion material?
Power — Will the Nano run the LED strip and sensor reliably, or do I need a separate 5V supply?
Code logic — How do I smooth the distance readings so the LEDs don't flicker?

These are the questions I'll answer by building.

Timeline

Day 1-2: Order parts, wait
Day 3: Wire up on breadboard, get sensor + LEDs working
Day 4: Write the behavior code (the gradation logic)
Day 5: Test the housing idea
Day 6: If it works, document. If not, debug.

I'll post updates as I go. Each dev log will cover one specific thing I tried — what worked, what didn't, what I learned.

Why I'm Sharing This

If you're trying to build something interactive, you might be in the same place I am now: reading about sensors, watching project videos, thinking about what you want to make.

This series is my attempt to actually do it. Not to create a polished tutorial — to show what it's like to go from "I want to make something that knows I'm there" to "I built something that knows I'm there."

I'll share the failures as honestly as the successes. The parts that don't work. The decisions I regret. The moments where something that should have taken an hour takes three.

That's the part tutorials leave out.

Dev Log #0 — the beginning. Parts on order.

The Moment Your Project Knows You're There

張旭豐 — Mon, 13 Apr 2026 15:24:12 +0000

The Moment Your Project Knows You're There

S1: The Feeling You Want to Create

There is a moment when something changes.

You walk toward a wall, and as you get closer — something shifts. Not because you touched anything. Not because you pressed a button. Just because you were there.

That's the moment this article is about.

On Behance, there is a project called The Dots — an interactive kinetic installation by Jack Lee. Seven circular panels arranged in a hexagonal grid, each coated with polarized film. You wear a special face shield, and as you approach the panels, they begin to rotate. The closer you get, the more the panels become transparent. Step back, and they fade again. The work is called DISTANCE TO DARKNESS.

Lee describes it as "Magic of Lights." Viewers call it "mesmerising." One person wrote that standing in front of it felt like watching a "visual symphony."

You may not have the tools to build The Dots. But you can build the core feeling it captures — and it takes less than you think.

S2: What Makes It Work

The magic of The Dots is not in the servo motors. It is not in the Arduino code. It is not in the polarized film.

It is in the fact that the installation knows you are there.

That one quality — responsiveness without contact — is what separates "interactive art" from "electronics project." Anyone can make an LED blink. Making an LED respond to someone's presence, the way a living thing might — that is the thing you actually want to learn.

Here is how it works at the most basic level:

A proximity sensor emits a signal (infrared or ultrasonic) and measures how long it takes for that signal to bounce back. The closer an object — like a human body — the stronger the return signal. An Arduino reads that signal strength as a number.

That number can then be used to control something. An LED brightness. A servo rotation angle. The rate at which bubbles form in a wall. The transparency of a polarized panel.

The chain is always the same:

Proximity > Signal > Decision > Response

Your project does not need to be complex. It needs to be responsive. The moment your project reacts to the world around it — without being told what to do — it becomes something more than the sum of its parts.

S3: The Simplest Version of This Moment

You can feel this in under ten minutes.

What you will build:

A single LED that turns on when your hand gets close to a sensor. No buttons. No code you need to understand first. Just proximity — and response.

What you will need:

Arduino Uno (or Nano)
IR proximity sensor (Sharp 2Y0A21, approximately $6-10)
LED (any color)
220 Ohm resistor
Breadboard and jumper wires

That is all. No soldering. No prior experience.

Here is what the IR proximity sensor looks like. This is the component that lets your project "feel" when something is nearby:

The wiring:

Arduino 5V  > Sensor VCC (red wire)
Arduino GND > Sensor GND (black wire)
Arduino A0  > Sensor OUT (white/yellow wire)
Arduino D9  > LED (+) through 220 Ohm resistor
Arduino GND > LED (-) (short leg)

This is what the assembled circuit looks like on a breadboard:

The code:

const int sensorPin = A0;
const int ledPin = 9;

void setup() {
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT);
}

void loop() {
  int value = analogRead(sensorPin);
  // With nothing nearby: value around 500-600
  // With hand 5-10cm away: value drops to 100-200

  if (value < 200) {
    digitalWrite(ledPin, HIGH); // It knows you're there
  } else {
    digitalWrite(ledPin, LOW);  // You're too far
  }
}

What just happened:

You made something that responds. Not something that runs a program you wrote. Something that reacts to the world — to you — the way The Dots does, the way Bubble Wall does, the way every interactive installation you have ever admired does.

The complexity of the project does not change this fact. A proximity-triggered LED and a wall of polarized panels operate on the same principle. The difference is only in scale.

S4: Building on That Moment

Once you have felt the basic response, you can extend it in two directions.

Scale the response:

Instead of just on/off, use PWM (Pulse Width Modulation) to make the LED fade gradually as you approach. This is how The Dots creates its smooth transitions — not sudden changes but continuous, analog-feeling responses.

int brightness = map(value, 50, 600, 255, 0);
brightness = constrain(brightness, 0, 255);
analogWrite(ledPin, brightness);

Change the trigger:

Proximity is one option. Here are other ways your project can "know" you are there:

What you want to detect	Sensor	Approximate cost
Distance / presence	IR (Sharp 2Y0A21) or Ultrasonic (HC-SR04)	$5-10
Light level in the room	Photoresistor (LDR)	under $1
Sound / clap	Electret microphone module	$2-3
Touch without contact	Capacitive touch (MPR121)	$10-15
Temperature nearby	TMP36	$1-2

Change the response:

The LED can become anything:

A solenoid pushing a physical object
A servo motor rotating a panel or arm
A valve opening to release air or mist (this is how Bubble Wall works)
A motor changing speed instead of just turning on and off

The Dots uses servo motors to rotate panels. Bubble Wall uses solenoid valves to control mist. The principle is the same — a sensor reading translated into motion.

S5: The Realization

Go back to The Dots. Read the description again:

"As the panels rotate, the relative angle between the polarised film on the panels and the viewer's face shield changes. This change in angle alters the transmission of light through the panels, affecting their transparency. When the polarisation angles align, the panels become more transparent, allowing more light to pass through."

Now go back to what you built in ten minutes:

A sensor reading a number. That number controlling whether an LED is on or off.

The Dots and your breadboard project are not different in kind. They are only different in scale.

Every complex interactive installation — the ones that fill galleries, the ones that go viral on design websites, the ones that make people stand in front of them for minutes — is built from this same basic chain. Sensor. Signal. Response.

You do not need to know everything before you start. You need to start with the feeling you want to create — and build the simplest possible version of that feeling first.

If you want to learn more about translating feelings into components, here is the framework:

Step 1: Write one sentence describing what you want the viewer to feel.
"When someone walks by, I want them to feel like the space is watching them."

Step 2: Identify what triggers the change.
"When someone gets close" > proximity sensor.

Step 3: Identify the type of response.
"The space should react, not just turn on" > gradual response, not binary.

Step 4: Choose the component that matches.
Proximity + gradual response > PWM-controlled output.

That is the entire framework. Not a worksheet. Not a decision tree. Just this:

What do you want them to feel? What tells the system they are there? How should it respond?

If you can answer those three questions, you can build anything in this space.

S6: What to Build Next

If you want to keep it simple:

A proximity-triggered LED is complete. To extend it: make it fade instead of just turning on/off. Then make it change color based on distance (RGB LED). Then add a second sensor.

If you want to scale toward The Dots:

Try a servo motor that rotates as you approach. The principle is identical — proximity reading controls motor angle instead of LED brightness.

If you want to see what this looks like at full scale:

The Bubble Wall project on Hackster documents a maker who built an interactive inflatable panel — a wall that produces bubbles in response to proximity. Read their project notes. Look at the photos. See how a simple idea at the component level becomes something that looks alive.

The feeling you are chasing — "it knows I'm here" — is not a technical achievement. It is a design achievement. The components are not the hard part. The hard part is deciding what feeling you want to create — and being willing to build toward it.

If this made you want to start building something, good. Go make the proximity LED first. Everything else comes from there.

Project References:

The Dots by Jack Lee — https://www.behance.net/gallery/174814713/The-Dots-Interactive-Kinetic-Installation
Bubble Wall Interactive Inflatable Panel — https://www.hackster.io/bubblesandclouds/bubble-wall-interactive-inflatable-panel-1c80fa

From Feeling to Firmware: Build Your First Sound Reactive LED Installation in 10 Minutes

張旭豐 — Sun, 12 Apr 2026 10:19:59 +0000

From Feeling to Firmware: Build Your First Sound Reactive LED Installation in 10 Minutes

Imagine walking into a room where the walls breathe with the music. Every bass hit sends ripples of color across the ceiling; every whisper of high frequency catches light like scattered stars. The room doesn't just play music — it responds to it. You feel the sound before you hear it.

You've tried this before. Maybe you googled "arduino sound sensor" and found a tutorial that told you to wire a microphone to pin A0, copy some code, and bam — an LED blinks. It felt flat. Mechanical. Not what you imagined.

That's the gap this guide fills. Not "how to connect a sound sensor to Arduino." Instead: how do you map what you feel in music to parameters that make an LED installation feel alive?

By the end, you'll have built a working sound reactive LED installation — and more importantly, you'll understand why each decision was made.

Why This Feeling, Why These Components

The problem with most sound sensor tutorials: They treat sound as binary — loud or quiet, on or off. That's not how humans experience music.

The MAX9814 microphone module solves this differently. It has automatic gain control, which means it adjusts to the ambient sound level automatically. In a quiet room, it amplifies subtle sounds. At a party, it doesn't clip. You get a smooth analog signal that maps naturally to human perception — not just "noise detected."

Why an 8×8 LED matrix instead of a single LED? Because a single LED can only be bright or dark. A matrix creates patterns — a column of light that rises with the beat, a cascade that flows with melody. Your audience reads spatial information instantly, below conscious thought. That's what makes it feel emotional instead of technical.

The Arduino Nano fits in your palm, runs on USB power, and has enough analog pins for this project without the complexity of shields or displays.

Bill of Materials

Before you start, grab these components:

MAX9814 sound module: https://www.amazon.com/s?k=MAX9814+sound+module+arduino
8×8 LED matrix (with MAX7219 driver): https://www.amazon.com/s?k=MAX7219+8x8+LED+matrix+arduino
Arduino Nano: https://www.amazon.com/s?k=Arduino+Nano+ATmega328P+USB

Optional (for cleaner power):

100µF capacitor across VCC and GND
Breadboard and jumper wires

Total: approximately $8-15 depending on where you shop.

Build Steps

Step 1: Connect the MAX9814 VCC to Arduino 5V, GND to GND, and OUT to analog pin A0. Add a 100µF capacitor between 5V and GND on the breadboard to smooth power fluctuations.

Step 2: Connect the MAX7219 LED matrix to the Arduino: VCC to 5V, GND to GND, DIN to pin 11, CLK to pin 13, CS to pin 10.

Step 3: Install the LedControl library in the Arduino IDE (Sketch → Include Library → Manage Libraries → search "LedControl").

Step 4: Upload the code below. The threshold value of 150 was chosen because it sits comfortably above typical ambient room noise (typically 80-120 on the analog scale) while still responding to speech and music at normal volumes.

Step 5: Open the Serial Monitor at 9600 baud. Speak normally and watch the analog values. Adjust the threshold variable in the code until the LED starts responding to your voice but stays quiet during silence.

Step 6: Play music through a speaker at normal volume. The matrix should pulse with the beat. If it's too sensitive, raise the threshold. If it's not responsive enough, lower it.

The Code

#include <LedControl.h>

// Pin definitions
const int SOUND_PIN = A0;      // MAX9814 output
const int DIN_PIN   = 11;      // MAX7219 DIN
const int CLK_PIN   = 13;      // MAX7219 CLK
const int CS_PIN    = 10;      // MAX7219 CS

// Sound-reactive parameters
// Threshold: ambient room noise is typically 80-120 on analogRead scale
// Setting threshold above ambient means only intentional sounds trigger
const int THRESHOLD = 150;

// Time-based filtering: smooths response to feel natural, not jittery
const unsigned long ATTACK_TIME = 50;   // ms - how fast LEDs respond to sound
const unsigned long RELEASE_TIME = 200; // ms - how slowly they fade back

LedControl lc = LedControl(DIN_PIN, CLK_PIN, CS_PIN, 1);

// State tracking for smooth response
int currentLevel = 0;       // Current LED brightness level
int targetLevel = 0;         // Where we're heading
unsigned long lastUpdate = 0;

void setup() {
  lc.shutdown(0, false);    // Wake up the MAX7219
  lc.setIntensity(0, 8);     // Set brightness (0-15)
  lc.clearDisplay(0);
  Serial.begin(9600);
}

void loop() {
  int soundLevel = analogRead(SOUND_PIN);
  Serial.println(soundLevel);  // Use Serial Monitor to calibrate threshold

  // Map sound level to target brightness
  if (soundLevel > THRESHOLD) {
    // Map the range above threshold (150-1023) to LED level (0-8)
    targetLevel = map(soundLevel, THRESHOLD, 800, 0, 8);
    targetLevel = constrain(targetLevel, 0, 8);
  } else {
    targetLevel = 0;  // Silence → no light
  }

  // Smooth the transition: fast attack, slow release
  // This is what makes the response feel "musical" instead of "digital"
  unsigned long now = millis();
  if (targetLevel > currentLevel && now - lastUpdate > ATTACK_TIME) {
    currentLevel++;
    lastUpdate = now;
  } else if (targetLevel < currentLevel && now - lastUpdate > RELEASE_TIME) {
    currentLevel--;
    lastUpdate = now;
  }

  // Visualize: columns rise from bottom based on level
  lc.clearDisplay(0);
  for (int col = 0; col < 8; col++) {
    lc.setColumn(0, col, (1 << currentLevel) - 1);
  }

  delay(5);  // Small delay prevents flickering
}

Why These Decisions

Why map() from threshold to 800, not to 1023?

The top of the analog range (800-1023) usually represents extreme, painful loudness — not music. Using 800 as the ceiling means the maximum LED brightness corresponds to "loud but comfortable" sound. This keeps the installation responsive without feeling aggressive.

Why separate attack and release times?

An LED that snaps on instantly and fades slowly feels like a heartbeat — the attack time of 50ms is fast enough to catch transients (drums, percussion hits) but slow enough to prevent jitter. The release time of 200ms means the light fades gracefully when sound stops, which feels more like "breathing" than "switching."

This is the design choice most tutorials skip: temporal mapping. You're not just mapping amplitude, you're mapping rhythm. That's what separates "it blinks" from "it breathes."

QA Guardrails

Step 3 (Library Install): IF the Arduino IDE shows "Library installation failed" CHECK that you have an active internet connection and try searching for "LedControl" instead of "MAX7219" — some libraries have different internal names.

Validation Checklist

Before you call this done, verify these five things:

Does the LED respond within 500ms of a sudden sound? Walk into the room and clap once. The matrix should light within half a second. If not, lower your threshold by 20.
Does the brightness map naturally to sound level? Whisper, then speak normally, then shout. You should see three distinct, proportional levels — not just "on" and "off."
Does the threshold sit above ambient noise? With the room silent, the matrix should stay dark. If it flickers randomly, raise the threshold by 10.
Does the light fade gracefully when sound stops? A sudden cut-off feels mechanical. You want a smooth fade over about 200ms. If the fade is too slow, lower RELEASE_TIME. If it's too fast, raise it.
Does the system recover correctly after a very loud sound? After a loud burst, does the matrix return to normal responsiveness within 2 seconds? If not, check that your power supply can deliver 5V consistently.

What Comes Next

You've built something that works. But here's the question this guide doesn't answer: why did you choose these parameters?

The threshold of 150. The attack time of 50ms. The release time of 200ms. I gave you these numbers — but if you want to build something that feels different (more aggressive, more gentle, more musical), you need to understand why these numbers create that feeling.

That's the gap between copying a project and designing one.

If you want to learn how to make those decisions yourself — how to tune an installation for a specific emotional quality, how to choose sensors based on the feeling you want rather than the tutorial you found — that's what the paid version of this guide teaches.

You already know how to build. Now you're ready to learn how to design.

This article is part of the "From Feeling to Firmware" series — where we build interactive devices that feel right, not just work right.

From Feeling to Firmware: Build a Sound Reactive LED That Responds the Way You Want

張旭豐 — Sun, 12 Apr 2026 04:54:03 +0000

From Feeling to Firmware: Build a Sound Reactive LED That Actually Responds the Way You Want

You walk into a room. The music plays. Light pulses with the beat — not a disco flash, but something gentler. Like the room is breathing with the music. You think: I want to build that.

You've tried. You wired a sound sensor, uploaded some code, and got an LED that blinks. It's either too sensitive — flickering from background noise — or not responsive enough. You have to shout to trigger it. It feels mechanical. Not what you imagined.

This guide is about mapping sound to light in a way that feels intentional. Not "connect a sensor to an LED." Instead: what do you want the audience to feel, and how does that map to a specific parameter choice?

What You Will Build

A sound-reactive 8×8 LED matrix driven by an Arduino Nano. The response follows a smooth rise-and-fade pattern that tracks the energy in the room — not a binary on/off.

By the end you will have:

A working sound-to-light mapping
A calibration method you can reproduce in any room
An understanding of why each parameter is where it is — and what changes when you adjust it

What This Guide Does Not Cover

This is not a "copy and it works" tutorial. It is a "follow along and understand why it works" tutorial. If you just want to replicate the result, you can copy the code and wiring. But if you want to know why 150 is the threshold, why 50ms and 200ms for timing, and what happens when you change them — this guide is for you.

Component Selection: Why MAX9814

The MAX9814 is not the only microphone module, and it is not automatically the best choice for every sound-reactive project. Here's the honest breakdown.

Where MAX9814 excels:

Built-in Automatic Gain Control (AGC) — the module adjusts its own sensitivity based on ambient volume
This means you get a smooth output signal across a wide dynamic range without manually calibrating gain potentiometers
In a quiet room: it amplifies subtle sounds. At a party: it doesn't clip. The output maps naturally to human loudness perception

Where MAX9814 falls short:

AGC response time is ~1ms minimum, which means fast transients (rim shots, snare attacks) are already compressed before they reach your Arduino
The output is "compressed loudness" — not actual decibel levels. You cannot use it to measure absolute sound pressure
In very loud environments (>90dB), AGC will always compress, so the output signal stays in roughly the same range regardless of actual volume

When to use something else instead:

If you need to capture fast musical transients accurately → use an electret capsule with a fixed-gain op-amp circuit (you calibrate the gain once, and the output is linear to actual voltage)
If you need to measure absolute decibel levels → use a module with a data sheet that specifies sensitivity (e.g., analog MEMS microphones with dB SPL specifications)
If your environment is extremely loud and you want the LED to go crazy at peaks → AGC compression will fight you; a manual gain circuit gives you direct control

For this project — ambient installation in a typical room, tracking musical energy with a smooth breathing response — MAX9814's AGC is the right tool. But it is a tradeoff, not an obvious best choice.

Bill of Materials

MAX9814 microphone module with AGC: https://www.amazon.com/s?k=MAX9814+microphone+module+arduino
8×8 LED matrix with MAX7219 driver: https://www.amazon.com/s?k=MAX7219+8x8+LED+matrix
Arduino Nano (any model with ATmega328P): https://www.amazon.com/s?k=Arduino+Nano+ATmega328P+USB
100µF electrolytic capacitor (for power smoothing)
Half-size breadboard and jumper wires

Wiring: Step by Step

Step 1 — Power the MAX9814

Connect:

MAX9814 VCC → Arduino 5V
MAX9814 GND → Arduino GND

The MAX9814 needs 5V. It will not work correctly on 3.3V — the AGC circuit requires the higher voltage to function.

What you should see: None yet — the module has no indicator LEDs. You are establishing power rails only.

IF you measure 0V between MAX9814 VCC and GND → CHECK your Arduino is powered (try a different USB cable or port). A laptop USB that cannot supply 500mA will cause the Arduino to appear dead.

IF the voltage reads 3.3V instead of 5V → CHECK you are plugged into the Arduino's 5V pin, not the 3.3V pin.

Step 2 — Connect the Audio Output

Connect:

MAX9814 OUT → Arduino analog pin A0

The audio output swings between 0V and approximately 0.6× VCC (about 3V at 5V supply). This is a bias voltage centered around 0.3× VCC — the signal swings above and below that midpoint. Arduino's ADC treats this as a normal 0–1023 range.

What you should see: Nothing visual here, but the Serial Monitor will show you the live reading in the next section.

Step 3 — Wire the LED Matrix (MAX7219 Driver)

The MAX7219 communicates via SPI. You need three control pins:

MAX7219	Arduino Nano
DIN	Pin 11
CLK	Pin 13
CS	Pin 10
VCC	5V
GND	GND

Also add a 100µF capacitor between 5V and GND on the breadboard. This smooths current demand spikes from the LED matrix.

IF the LED matrix shows nothing after you upload the code → CHECK the wiring order: DIN → Pin 11, CLK → Pin 13, CS → Pin 10. Swapping CLK and CS is the most common error and produces a blank display with no error message.

IF the matrix flickers randomly when there is no audio input → CHECK the 100µF capacitor is correctly placed across 5V and GND with the correct polarity. The capacitor body has a stripe — that side is the negative leg and connects to GND.

IF you see the correct pattern but it disappears after a few seconds → CHECK your power supply can deliver enough current. The LED matrix can draw over 200mA at full brightness. A laptop USB port may droop under this load.

Real breadboard wiring example. Your MAX9814 + MAX7219 setup follows the same layout pattern.

SPI wiring detail: DIN=Pin 11, CLK=Pin 13, CS=Pin 10. These pins are labeled on most MAX7219 modules.

This is the target behavior: LED matrix responding to music with smooth rise and fade.

The Parameters: How I Chose Them

This is the section most tutorials skip. They give you the numbers and tell you "tune to taste." Here is how the numbers were actually derived.

THRESHOLD = 150

Measurement environment:

Apartment living room, daytime, laptop fan + HVAC audible in background
MAX9814 module on breadboard, approximately 30cm from laptop speakers

Measured values:

Ambient (silence, no movement): 80–120 on Arduino ADC scale
Normal speech at 1m: 200–400
Loudspeaker music at comfortable volume: 400–700
Maximum output (near-field shout): 800–900

Why 150 specifically:
150 is the midpoint between my measured ambient ceiling (120) and my measured speech floor (200). This gives approximately 30 counts of headroom above ambient noise, and roughly 50 counts of margin below a normal speaking voice.

What happens if you change it:

THRESHOLD	Behavior
100	LED lights from faint ambient noise. Room fan, HVAC, and distant speech all trigger it. Too sensitive for most rooms.
150	Ambient noise stays dark. Normal conversation does not trigger. Loud music and clapping do. This is the working range for a typical room.
250	You need to produce actual loud sounds to trigger it. Ambient and speech are both rejected. Use this in noisy environments (cafes, bars).
350	Only very loud sounds trigger it. Effective only if the room is already loud and the LED is meant to highlight peaks rather than respond continuously.

Your room will have different ambient levels. Measure yours first, then choose your threshold based on the table above — not by copying 150 blindly.

ATTACK_TIME = 50ms

What this parameter controls: How quickly the LED rises toward the target level when sound crosses the threshold.

Measurement approach:
Played music from a laptop at desk distance. Watched the LED response while adjusting ATTACK_TIME from 10ms to 500ms. Evaluated by whether the LED "caught" percussion hits (kick drum, snare) without producing visible jitter.

Results at different ATTACK_TIME values:

ATTACK_TIME	Percussion Response	Perceived Quality
10ms	Catches attacks instantly. LED is jittery on any amplitude variation. Visually noisy.
30ms	Catches most attacks. Slight shimmer on sustained notes. Borderline jittery.
50ms	Catches attacks with a slight fade-in. Smooth on typical music. No visible jitter.
100ms	Attacks are noticeably delayed. Feels sluggish. Responds more to sustained energy than transients.
200ms	Very slow. Only the average energy of a phrase lights the LED. Musical dynamics are largely lost.

50ms is the point where the LED tracks individual beats without jittering on amplitude noise. This is a musical tempo threshold — not a technical minimum.

Why not faster?
Below ~30ms, the LED starts tracking amplitude noise that exists within a single musical note. This is not musically meaningful — it is just microphone self-noise and room ambiance. You are not trying to reproduce the waveform; you are trying to reproduce the beat.

RELEASE_TIME = 200ms

What this parameter controls: How slowly the LED falls from the target level back to zero when sound stops.

Results at different RELEASE_TIME values:

RELEASE_TIME	Visual Effect
50ms	Sharp on, sharp off. LED tracks amplitude precisely but feels mechanical. No sense of aftermath.
100ms	On-off with a slight fade. Beginning of the "breathing" quality.
200ms	Smooth fade after each beat. LED clearly decays even if the sound is sustained. Creates the "enveloped" feeling.
400ms	Decay is slow enough to overlap with the next beat. LED stays lit during most of a phrase. Calm, almost meditative quality.
800ms	Very slow. LED accumulates and stays on. Good for ambient drones, poor for anything with distinct rhythm.

200ms creates a decay that is long enough to feel smooth but short enough to clear before the next beat in a typical 120bpm track arrives (500ms per beat). The LED breathes between beats.

Why different from ATTACK_TIME?
The attack is fast because you want the LED to feel like it is "responding." The release is slow because you want the LED to feel like it is "sustaining." Fast attack + slow release is the opposite of a natural acoustic response — and that contrast is what creates the "alive" quality.

The Code: With Context

#include <LedControl.h>

const int SOUND_PIN = A0;
const int DIN_PIN   = 11;
const int CLK_PIN   = 13;
const int CS_PIN    = 10;

// THRESHOLD: above your measured ambient floor, below your measured speech level
// Measure in Calibration section first. 150 is a starting point, not a universal constant.
const int THRESHOLD = 150;

// ATTACK_TIME: how many milliseconds between LED brightness steps when sound is rising
// 50ms = one step every 50ms → reaches full brightness in 400ms (8 steps × 50ms)
// Too fast = jittery. Too slow = sluggish.
const unsigned long ATTACK_TIME = 50;   // milliseconds

// RELEASE_TIME: how many milliseconds between LED brightness steps when sound is falling
// 200ms = one step every 200ms → takes 1.6 seconds to fully fade out
// The asymmetry (fast attack / slow release) is intentional
const unsigned long RELEASE_TIME = 200; // milliseconds

LedControl lc = LedControl(DIN_PIN, CLK_PIN, CS_PIN, 1);

int currentLevel = 0;       // LED brightness level right now (0–8)
int targetLevel = 0;         // Where the LED is trying to go
unsigned long lastUpdate = 0;

void setup() {
  lc.shutdown(0, false);    // Wake up MAX7219 (it powers on in shutdown mode)
  lc.setIntensity(0, 8);   // Brightness setting (0–15); 8 is comfortable for indoor use
  lc.clearDisplay(0);
  Serial.begin(9600);      // Used for calibration — open Serial Monitor at 9600 baud
}

void loop() {
  int soundLevel = analogRead(SOUND_PIN);
  Serial.println(soundLevel);  // Print every reading for calibration

  // Map sound to LED level only when sound crosses the threshold
  // The "if (soundLevel > THRESHOLD)" creates a dead zone below threshold
  if (soundLevel > THRESHOLD) {
    // Map from THRESHOLD to 800 — NOT from 0 to 1023
    // 800 is the ceiling: loud-but-not-painful maps to full brightness
    // Above 800, MAX9814 output is already clipping; no useful musical info there
    targetLevel = map(soundLevel, THRESHOLD, 800, 0, 8);
    targetLevel = constrain(targetLevel, 0, 8);
  } else {
    targetLevel = 0;
  }

  // Smooth transition with asymmetric timing
  unsigned long now = millis();
  if (targetLevel > currentLevel && now - lastUpdate > ATTACK_TIME) {
    currentLevel++;
    lastUpdate = now;
  } else if (targetLevel < currentLevel && now - lastUpdate > RELEASE_TIME) {
    currentLevel--;
    lastUpdate = now;
  }

  // Display: columns rise from the bottom based on currentLevel
  lc.clearDisplay(0);
  for (int col = 0; col < 8; col++) {
    lc.setColumn(0, col, (1 << currentLevel) - 1);
  }

  delay(5);  // Small delay prevents the loop from hogging 100% CPU
}

Key design decision — why map from THRESHOLD to 800 instead of 0 to 1023?

0-to-1023 mapping: If ambient noise reads 80, then 80 counts of "silence" still maps to LED brightness. Your LED will be dimly lit when the room is quiet.

THRESHOLD-to-800 mapping: The full range of interest (above ambient, below clipping) maps to the full LED range. A quiet room stays off. A loud room reaches maximum brightness. The ceiling of 800 reflects where MAX9814 output saturates at comfortable listening levels — above 800 you are in clipping territory and the output no longer represents "louder" accurately.

Calibration: Finding Your Numbers

THRESHOLD = 150 was measured in my room. Your room will be different. Follow this procedure to find your own values.

Upload the code and open the Serial Monitor at 9600 baud.
Leave the room quiet. Close windows, pause music, stop typing. Wait 5 seconds. Read the value. This is your ambient noise floor.
Have a conversation at normal volume, or read a paragraph aloud. Read the value during normal speech. This is your speech level.
Play music at the volume you expect during the installation. Read the value. This is your music level.

Your goal: Set THRESHOLD to a value above your ambient floor but below your speech level. Use the table below to interpret the results:

Condition	What it means	Adjustment
LED lights during silence	Threshold is below ambient floor	Raise threshold by 20–30
LED does not respond to normal music	Threshold is above music level	Lower threshold by 20–30
LED responds to speech	Threshold is too close to speech level	Raise threshold by 10–20
Everything triggers it, even footsteps	Threshold is far too low	Raise threshold by 50+

IF your ambient is above your speech level (e.g., you measure ambient at 300 because you are in a loud cafe) → the LED will always be on. This setup is not appropriate for that environment. You need either a directional mic pointed at a sound source, or a louder sound source, or a different threshold strategy (e.g., change-only detection rather than level detection).

Calibration is about finding your specific numbers — ambient floor, speech level, and music level — then choosing a threshold that sits between them.

Validation: A Test You Can Actually Run

Do not answer these questions in your head. Go do them.

Test 1 — Responsiveness

Test: Clap your hands once, or drop something nearby.

Expected: The LED matrix responds within one second. You should see the columns rise from the bottom.

Pass criteria: The matrix lights within one second of the sound event.

If it fails: Check Serial Monitor — you should see a reading above THRESHOLD. If you see a value above 150 but the LED does not light, check your wiring (DIN=Pin 11, CLK=Pin 13, CS=Pin 10). If the Serial Monitor shows values below THRESHOLD, lower your threshold to 100 and repeat.

Test 2 — Silence Rejection

Test: Sit in the room with no music playing. Wait 30 seconds.

Expected: The matrix stays dark. Faint sounds (HVAC, distant traffic) do not trigger it.

Pass criteria: No LED activity for 30 seconds in a quiet room.

If it flickers: Your ambient floor is higher than your THRESHOLD. Measure your quiet room reading and raise THRESHOLD to (your ambient floor + 20).

Test 3 — Loud Music Response

Test: Play music at the volume you intend to use for the installation.

Expected: The LED matrix reaches full brightness (all 8 columns lit) during the loudest parts of the track.

Pass criteria: At least 5–6 columns light during peaks.

If it does not reach full brightness: Either your THRESHOLD is too high, or your music level is not reaching the MAX9814 effectively. Try lowering THRESHOLD to 120 and repeating Test 1 and Test 2 simultaneously.

Test 4 — Attack Speed (Percussion Tracking)

Test: Play music with clear percussion (kick drum, snare, hi-hat).

Expected: The LED responds to each drum hit with a visible brightness rise.

Pass criteria: You can see a distinct brightness pulse on each kick drum hit at 120bpm.

If the response feels sluggish: Lower ATTACK_TIME from 50ms to 30ms. If it becomes jittery, raise back to 40ms.

Test 5 — Release Quality

Test: With music playing, pause the music.

Expected: The LED fades smoothly over approximately 1–2 seconds, not instantly.

Pass criteria: You can see a visible decay of roughly 1–2 seconds after the music stops.

If it drops instantly: RELEASE_TIME is too low. Raise from 200ms to 400ms. If the decay feels too slow and starts blending with the next beat, lower to 150ms.

What This Build Is and Is Not

What it is:

An ambient installation that responds to musical energy in a room
A demonstration of temporal mapping (how the time constants of response create emotional quality)
A calibration process you can run in any room to find your own threshold

What it is not:

A precise decibel meter — the MAX9814 AGC compresses output, so the numbers on the Serial Monitor are not dB SPL values
A beat detector — this tracks amplitude envelopes, not onsets. It will not perfectly sync to the first beat of every measure.
A solution for every environment — in a nightclub or factory floor, the AGC will compress everything and the LED will barely respond. This is the right tool for living rooms, galleries, classrooms, and similar spaces.

What's Next

You now have a working sound-reactive installation. You also have the calibration method and the parameter tables — not just the code, but the logic behind each number.

The gap between this project and designing your own is not the code. It is the question: "what do I want the audience to feel, and which sound feature maps to that feeling?"

If you want to go further — different sensor types, different mapping strategies, different emotional qualities — the paid version of this guide walks through the design thinking process: how to choose a sensor based on the behavior you want, how to map sound features to light patterns, and how to debug when the result feels wrong instead of just following a different tutorial.

Link to the paid version will go here.

This article is part of the "From Feeling to Firmware" series — building interactive devices that feel right, not just work right.

震動馬達知多少？偏心馬達 vs 線性馬達 vs 伺服馬達

張旭豐 — Sun, 22 Mar 2026 11:14:01 +0000

震動馬達知多少？偏心馬達 vs 線性馬達 vs 伺服馬達

圖1：遊戲手把的觸覺回饋，讓沉浸體驗大幅提升

1️⃣ 場景：觸手可及的震動體驗

你拿起身機滑動機台，手機輕輕震了一下；
你拿起遊戲手把開槍，槍托傳來一陣後座力回饋；
智慧手錶的鬧鐘響起，輕敲手腕提醒你起床。

這些日常場景的背後，都有同一個關鍵元件在默默運作——震動馬達。

從手機、遊戲手把、穿戴裝置，到工業設備的警示系統，震動馬達無所不在。它讓冰冷的電子產品有了「觸覺」，成為人機介面中不可或缺的一環。

2️⃣ 需求：為什麼需要震動回饋？

震動回饋不是花俏功能，而是實用剛需。

通知與警示：在吵雜環境或會議中，視覺與聽覺通知可能失效，但震動觸感幾乎必定被察覺。這是手機「靜音模式」依然能靠震動提醒你的原因。

沉浸式體驗：遊戲手把的震動回饋，讓槍戰、賽車、格鬥遊戲的衝擊感大幅提升。少了震動，遊戲體驗就像看無聲電影。

操作確認：ATM 按鍵、遙控器、醫療器材的按鈕，透過震動讓使用者確認「按下去了」，提升操作信心。

無障礙輔助：對聽覺或視覺有障礙的使用者而言，震動是重要的訊息傳遞管道。

簡單說：震動是電子設備「說話」的方式之一，而且是那種你很難忽略的語言。

3️⃣ 感知：馬達如何產生震動？

震動的本質是物理運動的慣性。

馬達通電後，內部轉子開始旋轉（或直線來回運動）。當轉子質量分布不對稱時，旋轉會產生離心力；這個離心力傳遞到外殼，再傳遞到整個裝置——你就感受到震動了。

影響「震動感」的變數主要有三個：

變數	說明
頻率	震動的快慢，決定了感知的「粗細」——低頻粗獷有力，高頻細膩輕柔
振幅	震動的幅度，直接影響感受的強度
響應時間	從訊號輸入到馬達啟動的延遲，決定了回饋是否「跟手」

這三個變數的組合，就構成了三種主流震動馬達各自的性格。

4️⃣ 原理：三種馬達怎麼動？

🔵 偏心馬達（Eccentric Rotating Mass, ERM）

圖2：ERM 偏心馬達，透過偏心質量塊旋轉產生震動（Source: iNeedMotors）

最傳統、也最常見的震動馬達。

內部有一個偏心轉子——轉子軸心不在幾何中心上，因此旋轉時重心始終偏離旋轉軸，持續產生單一方向的離心力。

這股離心力推動外殼，外殼帶動整個裝置，就形成了震動。

特點：通電就轉、斷電靠摩擦慢慢停、無法精準控制起點與力道

🟢 線性馬達（Linear Resonant Actuator, LRA）

圖3：LRA 線性馬達，質量塊在直線方向來回移動產生震動（Source: TradeW）

一種利用電磁彈簧系統實現直線運動的馬達。

內部有一塊質量塊（mass）懸掛在彈簧上，線圈通電後產生磁場，推動質量塊沿直線來回移動。當驅動頻率與彈簧固有頻率吻合時，產生共振，震動效率最大化。

特點：響應速度快，可透過調整頻率與振幅控制震動細節，但行程固定，輸出力道有上限

🟠 伺服馬達（Servo Motor）

圖4：Arduino 伺服馬達，可精準控制角度與速度（Source: Wikimedia Commons）

結合了馬達、減速機與回饋感測器的整合系統。

透過回饋控制，精準控制轉速與角度，甚至可以回傳位置資訊。這讓震動模式可以非常複雜——不只是「轉快 / 轉慢」，而是能做到波形控制、漸強漸弱、特定節奏。

特點：精度最高，可回饋、可編程，缺點是體積大、功耗高，成本貴

5️⃣ 比較：三種馬達比一比

項目	偏心馬達 (ERM)	線性馬達 (LRA)	伺服馬達 (Servo)
響應速度	慢	快	中等
控制精度	低（僅開/關）	中（頻率+振幅）	高（位置+速度+力矩）
體積	小	薄型	大
功耗	低	中	高
成本	便宜	中等	昂貴
常見應用	手機、遙控器	旗艦手機，遊戲手把	機械設備、機器人、特殊遊戲周邊

6️⃣ 實作：常用 IC 與控制方式

如果你想動手做專案，以下是幾個常見方案：

驅動 IC 推薦

IC 型號	適用馬達	特點
DRV2605	LRA / ERM	I2C 控制，內建音圈馬達驅動電路，支援 haptic 波形
AD7298	ERM	簡單 PWM 控制，便宜好取得
L293D / TB6612	伺服馬達	雙H橋驅動，可控制方向與速度
ESP32 / Arduino	通用	搭配上述 IC 即可用程式控制震動模式

圖5：驅動電路圖
左側為 ESP32/Arduino MCU，中間為 DRV2605 驅動晶片，右側連接線性馬達（LRA）或偏心馬達（ERM）。電路包含：3.3V/5V 電源、RST 腳位上拉電阻、SDA/SCL I2C 訊號線，以及馬達兩端並聯的二極體（防反向電動勢）

控制邏輯簡述

偏心馬達的控制最簡單：PWM 訊號控制轉速，佔空比越高，震動越強。

線性馬達需要特定頻率驅動（通常 150～300Hz），偏離諧振頻率效果會大打折扣，建議使用 DRV2605 這類專用 IC 處理。

伺服馬達則需要角度指令：發送 PWM 或 UART 訊號指定目標位置，馬達內建回饋會自動修正。

7️⃣ 結尾：一句話總結

偏心馬達便宜實用，線性馬達是目前旗艦設備的主流選擇，伺服馬達則在需要精準控制的專業場景無可取代。 選對馬達，讓你的產品「震」到點上！

標籤：#震動馬達 #ERM #LRA #Arduino #觸覺回饋 #人機互動

HC-SR04 超聲波感測器完整教學：從接線到程式

張旭豐 — Sun, 22 Mar 2026 11:06:44 +0000

HC-SR04 超聲波感測器：原理與接線圖

圖1：倒車雷達是超聲波感測器最為人熟知的應用場景

🚗 場景

倒車雷達「嗶嗶嗶」響起時，你知道車子離牆面還有多近嗎？

答案就藏在今天的主角裡——HC-SR04 超聲波感測器。

🎯 需求

這篇要解決一個問題：

HC-SR04 是什麼？它怎麼測量距離？ Arduino 又怎麼接線與讀取數據？

不管你是 Maker 新手還是想搞懂原理的玩家，看完這篇就能動手做距離感測專案囉！

👀 感知

HC-SR04 使用的感知方式是超聲波測距。

就像蝙蝠在黑暗中飛行，靠的不是眼睛，而是發射超聲波 + 接收回聲來判斷障礙物的位置。

人類耳朵能聽到的聲音頻率約 20Hz～20kHz，而 HC-SR04 發射的超聲波頻率是 40kHz——超出人類聽覺範圍，所以我們完全聽不到。

圖2：HC-SR04 超聲波感測器模組，發射器（T）與接收器（R）分列兩端（Source: SparkFun, via Wikimedia Commons）

⚙️ 原理

🔊 怎麼測距離？

原理很簡單，分成三步：

發射：控制板發送一個 10μs 的觸發脈衝給感測器
飛行：感測器的超聲波發射器（Trig）發出超聲波，聲波向前跑，遇到障礙物反彈回來
接收：感測器的超聲波接收器（Echo）收到反射回來的超聲波

關鍵來了——聲波來回花了多少時間，我們是知道的！只要知道時間，就能算出距離。

簡單比喻：就像你在山谷裡喊「喂～」，2 秒後聽到回音，聲音來回花了 2 秒，聲速約 340m/s，所以山谷深度就是 340 × 2 / 2 = 340 公尺。

公式如下：

距離（cm）= (飛行時間 μs ÷ 2) × 0.0343

為什麼要除以 2？因為時間是來回的距離，我們只需要單程。

圖3：各式超聲波感測器，HC-SR04 是其中最常見的型號之一（Source: Wikimedia Commons）

🛠️ 實作

接線圖

HC-SR04 共有 4 支針腳，與 Arduino 的連接非常直覺：

HC-SR04 針腳	Arduino 接腳	說明
VCC	5V	電源正極
GND	GND	接地
Trig	Pin 9	觸發訊號（發射控制）
Echo	Pin 10	回聲訊號（接收讀取）

程式碼

// HC-SR04 超聲波測距範例
// VCC → 5V, GND → GND, Trig → Pin 9, Echo → Pin 10

const int trigPin = 9;   // 發射超聲波的針腳
const int echoPin = 10;  // 接收回聲的針腳

float duration;  // 飛行時間（微秒）
float distance;  // 距離（公分）

void setup() {
  Serial.begin(9600);           // 啟動序列埠，速率 9600
  pinMode(trigPin, OUTPUT);    // 設定 Trig 為輸出模式
  pinMode(echoPin, INPUT);     // 設定 Echo 為輸入模式
}

void loop() {
  // Step 1：發射超聲波
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);        // 發送 10μs 的觸發脈衝
  digitalWrite(trigPin, LOW);

  // Step 2：讀取回聲時間
  duration = pulseIn(echoPin, HIGH);

  // Step 3：計算距離
  distance = (duration * 0.0343) / 2;

  // Step 4：輸出到序列埠
  Serial.print("距離：");
  Serial.print(distance);
  Serial.println(" cm");

  delay(500);  // 每 0.5 秒測量一次
}

上傳燒錄程式碼後，打開 工具 → 序列埠監控視窗，就能看到距離數值持續更新。

圖4：Arduino 電路接線示意圖（Source: Wikimedia Commons）

⚖️ 比較

HC-SR04 vs 紅外線感測器（IR）

維度	HC-SR04 超聲波	紅外線 IR
測量距離	2cm～400cm	通常 < 80cm
精準度	±3cm	易受顏色/光線影響
測量介質	不受顏色影響	深色表面表現差
成本	便宜（≈ $1-2）	也便宜
適用場景	戶外、液位、robot	室內，近距離

結論：測距範圍大、精度高，而且不受障礙物顏色影響——這就是 HC-SR04 能廣泛用於倒車雷達、液位檢測、機器人避障的原因。

✅ 結尾

HC-SR04 是 CP 值最高的測距感測器之一，理解原理後你就能用它做出倒車雷達、液位計，甚至避障小車。

下一步，建議你試試看結合 Servo 馬達做一個超聲波雷達掃描器，用 Processing 畫出即時地形圖——保證驚豔！

圖5：停車場的車位感測器，就是超聲波測距技術的實際應用（Source: Wikimedia Commons）

🛒 所需零件

如果你還沒準備零件，以下是這篇教學需要的清單：

零件	用途
HC-SR04 超聲波感測器	本文主角
Arduino Uno R3	控制板
母對母杜邦線	接線必備
迷你麵包板	方便接線

閱讀時間約 4 分鐘｜字數：約 1,100 字

標籤：#HC-SR04 #超聲波感測器 #Arduino #測距 #倒車雷達 #Maker