LED Matrix

🎵 Audio Spectrum Visualizer

A real-time audio spectrum analyzer built from the ground up — dual custom PCBs, embedded DSP firmware on an ESP32-S3, and a complete software pipeline validated on Raspberry Pi before committing to silicon.

Table of Contents

1. Project Overview
2. System Architecture
3. Phase 1 — Software Proof of Concept (Raspberry Pi)
4. Signal Processing — FFT Pipeline
5. Custom PCB Design
   • Controller Board (2-layer)
   • LED Matrix Board (4-layer)
6. Power Architecture
7. Design Constraints & Trade-offs
8. Roadblocks & How They Were Solved
9. Firmware Architecture
10. Bill of Materials (Abridged)
11. Roadmap

Project Overview

This device listens to ambient audio, performs real-time FFT-based frequency analysis on an ESP32-S3, and renders a live spectrum visualization on a custom-designed 8×16 WS2812B RGB LED matrix. Three physical buttons allow standalone control of display mode, brightness, and visual theme — no PC, no monitor, no SSH required after initial flash.

Key design goals:

• Full hand-solderability — no reflow oven required (MEMS mic requires hot air; all other components are iron-solderable)
• Software-first validation: complete pipeline proven on Raspberry Pi before any PCB was committed to fab
• Justified component choices backed by real numbers: thermal dissipation analysis, power budget, signal integrity calculations
• Two fully custom PCBs: a 2-layer controller board and a 4-layer 8×16 LED matrix board

System Architecture

┌──────────────────────────────────────────────────────────────────┐
│                     CONTROLLER BOARD (2-layer)                   │
│                                                                  │
│  USB-C ──► 5V Rail ──► Buck Converter ──► 3V3 Rail              │
│                                │                                 │
│                         ESP32-S3-WROOM-1-N8                      │
│                         (dual-core Xtensa LX7, 240 MHz)          │
│                                │                                 │
│   ICS-43434 MEMS Mic ──► I2S ──┤                                 │
│   (24-bit, 64 dBA SNR)         │                                 │
│                                │                                 │
│   Button ×3 ──────────► GPIO ──┤                                 │
│   (color theme / gain / viz mode)  │                             │
│                                │                                 │
│   Native USB (D+/D−) ──────────┤  (flash + debug, no UART chip) │
│                                │                                 │
│                         GPIO1 ──► 330 Ω ──► JST-3 Header        │
└────────────────────────────────────────────────────────────────┬─┘
                                                                 │ 3-wire JST
                                                                 ▼
┌──────────────────────────────────────────────────────────────────┐
│                     LED MATRIX BOARD (4-layer)                   │
│                                                                  │
│  JST Header ──► DIN ──► WS2812B 8×16 Matrix (128 LEDs)          │

Phase 1 — Software Proof of Concept (Raspberry Pi)

Before committing to any PCB design, the complete audio-to-visuals pipeline was validated on a Raspberry Pi 4 using a USB microphone and an off-the-shelf WS2812B 8×32 matrix. This approach de-risked the DSP algorithm, the band-mapping logic, and the LED driving code as three independent concerns — completely decoupled from hardware design.

Software stack:

• Python 3, pyaudio for mic capture
• numpy.fft for FFT computation
• pygame for real-time visualization on HDMI monitor (development aid)
• rpi_ws281x for WS2812B LED matrix output

Validation milestones, achieved in sequence:

1. USB mic → raw sample capture → FFT computed in Python → bars rendered via pygame on HDMI ✅
2. Log-scaled FFT bins remapped to logarithmically spaced frequency bands → output to 8×32 matrix ✅
3. Peak-as-bar decay (instant attack, linear fall) tuned empirically — flickering eliminated while preserving fast musical transients ✅
4. Physical buttons wired to Pi GPIO with software debouncing — color theme, input gain, and visualization mode all selectable — fully standalone operation (no keyboard, no monitor, no SSH) ✅

Only after every milestone was confirmed working end-to-end was the custom PCB designed and sent to fab.

Signal Processing — FFT Pipeline

What the microphone actually outputs

The ICS-43434 MEMS microphone measures air pressure variations over time and digitizes them into a 24-bit I2S stream. This is a time-domain signal — a series of amplitude samples encoding when pressure changes occur. The microphone itself detects neither bass nor treble. Frequency extraction is entirely performed by the FFT in firmware.

The Fast Fourier Transform

The Fast Fourier Transform (FFT) is an O(N log N) algorithm for computing the Discrete Fourier Transform (DFT):

X[k] = Σ (n=0 to N-1)  x[n] · e^(−j2πkn/N)

Where:

• x[n] = time-domain audio samples from the I2S DMA buffer
• X[k] = complex-valued frequency-domain coefficient at bin k
• N = FFT window size — 2048 samples in this firmware (2× the per-chunk capture, so each FFT frame overlaps the previous one by 50%)
• k = bin index corresponding to physical frequency f = k · Fs / N

At Fs = 44.1 kHz, N = 2048 the bin spacing is Fs/N ≈ 21.5 Hz — fine enough to resolve kick-drum fundamentals around 40–60 Hz. Only the first N/2 bins are meaningful (Nyquist limit); the upper half is a conjugate mirror.

The implementation uses the ESP-DSP radix-2 single-precision routine dsps_fft2r_fc32 followed by dsps_bit_rev_fc32 — 2048 is 2^11 (not a power of 4), so radix-4 was not an option.

Pre-FFT conditioning — DC removal + Hanning window

MEMS microphones output samples with a DC bias that, if left untouched, would dump a huge spike into bin 0 and leak into its low-frequency neighbours. The firmware subtracts the per-window mean before applying a 2048-point Hanning window:

w[n] = 0.5 · (1 − cos(2π · n / (N − 1)))

Hanning suppresses spectral leakage from signal segments that aren't periodic in the window, at the cost of a known coherent-gain factor of 0.5 that is compensated for in the dBFS calibration below.

dBFS calibration

Every band level is expressed in dBFS — decibels relative to digital full scale — so the visualizer's dynamic range is deterministic regardless of input volume. With INMP441 24-bit samples right-shifted into int16 scale (INT16_FULL = 32768), a full-scale sine concentrated in a single bin produces:

|X[k]|_raw = (N / 2) · 0.5 · INT16_FULL = N · INT16_FULL / 4
              └─FFT scale─┘   └Hanning gain┘

Dividing each bin's magnitude by N · INT16_FULL / 4 therefore makes a full-scale single-bin tone read exactly 1.0 (= 0 dBFS) — a fixed reference that anchors every threshold downstream.

Logarithmic frequency band mapping + RMS-sum aggregation

24 bands are log-spaced from 30 Hz to 16 kHz so bass, mids, and treble each get roughly equal visual real estate, matching perceived pitch:

band_edge[i] = f_min · (f_max / f_min)^(i / N_bands)

Within each band the firmware sums power (|X[k]|²) across every FFT bin whose centre falls in [lo, hi), then takes a square root. This is energy-correct aggregation, the way professional RTAs do it: a full-scale tone in any single bin still reads 0 dBFS regardless of whether it lands in a narrow or wide band, while broadband content correctly accumulates the energy of all its bins instead of being washed out by averaging. For bands narrower than the bin spacing (which happens at the very bottom of the range — 21.5 Hz between bins), the firmware falls back to the bin nearest the band's geometric centre so the bar still registers.

The final per-band level is converted to dBFS with 20 · log10(magnitude), clamped from below to avoid log10(0).

Per-band EQ and display range mapping

A 24-element EQ curve in dB is added to each band's dBFS value to compensate for microphone frequency response — a mild bass lift to offset MEMS low-frequency roll-off, a mild presence lift in the upper mids. EQ in the log domain is mathematically clean: multiplicative gain becomes simple addition.

Final mapping clamps each band into the visual dynamic range:

display = clip( (bands_db + eq_db − DB_FLOOR) / (DB_CEIL − DB_FLOOR), 0, 1 )

With DB_CEIL = −18 dBFS (bar saturates) and DB_FLOOR = −45 dBFS (squelch — below this the bar reads zero). DB_FLOOR sits a few dB above typical mic self-noise so ambient room tone never flickers the bars at rest.

A coarse pre-FFT silence gate runs in parallel — if the raw int16 peak of the latest chunk is below SILENCE_PEAK_INT16 = 1500 (≈ −27 dBFS) the entire frame is treated as silence and skips the FFT entirely.

Peak-as-bar decay

Each band drives two animated quantities every frame:

bar_height -= BAR_FALL_RATE      // 0.04 / frame, linear fall
bar_height  = max(bar_height, current)

peak_mark  -= PEAK_FALL_RATE     // 0.015 / frame, slower
peak_mark   = max(peak_mark, current)

Both snap instantly upward whenever a band exceeds the current value. The bar falls fast enough to track musical dynamics; the peak marker — rendered as a dim white dot above the bar — falls slowly enough to leave a visible peak-hold trace. This is the same scheme used on the Raspberry Pi proof-of-concept, ported byte-for-byte.

Custom PCB Design

Controller Board (2-layer)

Hand-solderable 2-layer board hosting the ESP32-S3 module, MEMS microphone, power regulation, USB-C input, and user buttons.

Stackup: Standard 2-layer FR4, 1 oz copper.

MCU — ESP32-S3-WROOM-1-N8

Selection rationale:

• Compute headroom: Real-time 2048-point floating-point FFT, log-band aggregation, dBFS conversion, peak-bar animation, and WS2812B single-wire serialization all run concurrently. The dual LX7 cores at 240 MHz provide comfortable headroom — capture and DSP/render are split across the two cores via FreeRTOS task pinning. An ATmega328P at 16 MHz cannot handle simultaneous I2S DMA, floating-point FFT, and the tight timing requirements of WS2812B bit-banging without frame drops.
• Module form factor: The bare ESP32-S3 SoC is a QFN56 package requiring reflow. The WROOM-1 module exposes castellated edge pads, which are hand-solderable with a standard iron — consistent with the design's solderability requirement.
• Native USB: Eliminates an external USB-to-UART bridge IC (CH340, CP2102, etc.). Flashing and serial debug use the same USB-C connector as power.
• N8 variant specifically: Selected over R8/R16V to keep IO35–IO37 available as general-purpose GPIO.

Supporting circuitry follows Espressif's official ESP32-S3 Hardware Design Guidelines:

Microphone — ICS-43434

A fully integrated I2S MEMS microphone combining the MEMS transducer, analog signal conditioning, ADC, decimation filter, anti-aliasing filter, and power management internally.

No external ADC or audio codec is needed. All analog signal conditioning is internal, significantly simplifying the schematic and eliminating noise concerns around an external analog frontend.

Supply filtering: The buck converter on the same board switches at 500 kHz, injecting noise onto the 3.3 V rail. A 10 Ω / 10 µF RC low-pass filter on the ICS-43434 VDD pin attenuates this before it can corrupt the microphone's internal analog circuitry:

f_c = 1 / (2π × R × C)
    = 1 / (2π × 10 × 10×10⁻⁶)
    ≈ 1,592 Hz

Attenuation at 500 kHz switching frequency:
  f / f_c = 500,000 / 1,592 ≈ 314
  A = 1 / √(1 + 314²) ≈ 1/314 ≈ −50 dB

−50 dB attenuation at the switching frequency exceeds the accepted −40 dB threshold for sensitive mixed-signal supply filtering. The resistive voltage drop at 490 µA is 4.9 mV — well within the 1.65 V minimum supply margin.

SD pin: Pulled to GND through a 100 kΩ resistor to ensure the output line decays to a defined low state during the tristate period.

WS2812B Data Line — Signal Integrity

A 330 Ω series resistor is placed between GPIO1 and the first WS2812B DIN, as close to the MCU pin as practical. Purpose:

• Damping: Reduces transmission-line ringing caused by PCB trace inductance/capacitance interacting with fast GPIO switching edges.
• Transient current limiting:

I_transient ≈ V / R = 3.3 V / 330 Ω ≈ 10 mA  (instantaneous worst case)

• Rise time check: The RC time constant with the WS2812B input capacitance (~10 pF):

t_rise ≈ 2.2 × R × C = 2.2 × 330 × 10×10⁻¹² ≈ 7.3 ns

7.3 ns is well within the WS2812B's 200 ns minimum pulse width specification — the resistor damps ringing without distorting signal timing.

Logic level shifting: No level shifter IC is used. The WS2812B HIGH threshold is >0.7 × VDD = 3.5 V at 5 V supply, which is marginally above the ESP32-S3's 3.3 V GPIO output. This was validated experimentally during the Raspberry Pi proof-of-concept (the Pi's GPIO is also 3.3 V) before being carried forward to the PCB. At the trace lengths involved, 3.3 V logic drives the WS2812B reliably, eliminating a component from the BOM.

User Buttons

Three 12 mm × 12 mm SMD tactile pushbuttons, each mapped to a distinct runtime function:

Internal ESP32-S3 pull-up resistors are enabled in firmware. A timer-based software debounce (~20 ms lockout window) eliminates contact bounce without external RC networks.

LED Matrix Board (4-layer)

A custom 4-layer PCB housing 128 WS2812B RGB LEDs in an 8-row × 16-column grid. Designed from scratch rather than using an off-the-shelf panel, allowing exact physical dimensions, LED pitch, and layer stackup to be optimized for this enclosure.

Why 4 layers:
A dedicated ground plane on layer 2 provides a low-impedance return path for WS2812B switching currents, which can be large and fast (each LED draws up to 60 mA and switches on the 800 kHz data clock). The ground plane also reduces EMI from the LED data lines running across the board.

Decoupling strategy:

• 100 nF ceramic capacitor placed as close as physically possible to the VDD/GND pins of each LED cluster — absorbs high-frequency switching transients local to each LED
• 1000 µF bulk electrolytic at the board's power entry — handles large aggregate transient current when many LEDs update simultaneously

Connector: 3-position JST-PH SMD header (5V, GND, Data) on each board, connected via a short cable to the controller board.

Power Architecture

Input — USB-C

The device is powered from a standard USB-C 5 V supply. Per the USB-C specification, a UFP (device) must place 5.1 kΩ pull-down resistors on both CC1 and CC2 to signal its presence and request 5 V/900 mA from a host or charger. SBU1/SBU2 are left unconnected (only required for alternate modes such as DisplayPort). D+/D− are routed to the ESP32-S3 native USB PHY for flashing and debug.

5V Rail

The 5 V rail feeds the WS2812B matrix directly. LEDs are the dominant current consumer and are rated for 5 V operation.

3.3V Rail — Buck Converter

The 3.3 V rail (ESP32-S3, MEMS mic, logic) is stepped down from 5 V via a synchronous buck converter.

Why not an LDO — thermal analysis:

An LDO dissipates (V_in − V_out) × I_load as heat. At the ESP32-S3 peak current draw of 350 mA:

P_LDO = (5.0 − 3.3) V × 0.350 A = 595 mW

At a typical θ_JA of ~40 °C/W for a small SMD package, this raises junction temperature ~24 °C above ambient under sustained load with no heatsinking — unacceptable thermal stress for a hobby PCB.

A buck converter at ~88% efficiency dissipates:

P_out = 3.3 V × 0.350 A = 1.155 W
P_dissipated = P_out × (1/η − 1) = 1.155 × (1/0.88 − 1) ≈ 158 mW

Less than 27% of the LDO's dissipation. The buck converter was the clear choice.

Full System Power Budget

The design targets a 5 V / 5 A USB-C adapter. System peak current sits below the 5 A ceiling with margin.

3.3V Decoupling Network

Following Espressif hardware design guidelines for the ESP32-S3:

X7R dielectric was specified throughout for stable capacitance over temperature and DC bias (±15% over −55 to +125 °C). Y5V/Z5U alternatives can lose >50% capacitance under DC bias and were explicitly avoided.

ESD protection: A PESD3V3S1UB unidirectional TVS diode is placed at the 3.3 V rail entry per Espressif's recommendation.

Design Constraints & Trade-offs

Roadblocks & How They Were Solved

1. FFT output was visually noisy and impossible to read
Raw FFT magnitudes mapped linearly to LED height produced a constantly saturated, unreadable display. Resolution: applied 20·log10(|X[k]|) per bin for dB scaling, then grouped bins into logarithmically spaced frequency bands. This transformed the visualization into a clean, perceptually balanced spectrum with clear bass, mid, and treble separation.

2. Display flickering between frames
Frame-to-frame FFT variation was fast enough to cause severe LED flickering. Resolution: a peak-as-bar animation with instant attack and linear decay (bar -= BAR_FALL_RATE, snap up on any larger sample), plus a separate slower-decaying peak-hold marker. Decay rates were tuned empirically during the Pi phase to balance smooth fall against visual reactivity, and the same constants were carried over to the ESP32 port.

3. LDO thermal concern on 3.3V rail
Initial design considered an LDO for simplicity. Thermal analysis revealed 595 mW peak dissipation — unacceptable for an SMD package on a hobby board with no thermal management. Buck converter selected; RC filtering on the mic supply mitigates the switching noise introduced.

4. WS2812B logic level margin
The WS2812B HIGH threshold (3.5 V at 5 V supply) exceeds ESP32-S3 GPIO output (3.3 V). Rather than adding a level shifter IC, this was validated experimentally on the Raspberry Pi (also 3.3 V GPIO) before the PCB was designed. Validated reliable at relevant trace lengths — the level shifter was eliminated from the BOM.

5. Buck switching noise on microphone supply
Concern that 500 kHz switching noise would corrupt audio captures. Resolved with a 10 Ω / 10 µF RC low-pass filter on the ICS-43434 VDD pin, providing −50 dB attenuation at the switching frequency — exceeding the −40 dB threshold considered best practice for mixed-signal supplies.

Firmware Architecture

The firmware lives under Firmware/ESP32Firmware/ as a PlatformIO project targeting Arduino-ESP32 v3.x (ESP-IDF 5.x). FFT runs on the bundled ESP-DSP component; the WS2812B chain is driven by FastLED over the ESP32's RMT peripheral. Capture and DSP/render are split across the two cores using FreeRTOS task pinning:

Core 0  ── i2s_capture task                       Core 1  ── dsp_render task
──────────────────────────────────                ───────────────────────────────────────
i2s_std driver (INMP441, MONO, LEFT slot)
  44.1 kHz · 32-bit slot · DMA pool 8 × 256
        │
        │  blocking read of CHUNK_SIZE samples
        ▼
sample >>= 16   (24-bit → int16, preserves
                 the int16 dBFS reference)
        │
        ▼
xQueueSend(audioQueue, …, 0)   ─────────────────► xQueueReceive(audioQueue, …, portMAX_DELAY)
  length 2, drop-oldest on full                          │
  (keeps I2S DMA hard real-time)                         ▼
                                                  silence gate on raw int16 peak
                                                         │
                                                         ▼
                                                  dsp_push_chunk
                                                    rolling 2048-sample window
                                                    shifts left, newest chunk appended
                                                         │
                                                         ▼
                                                  dsp_compute_bands
                                                    DC removal

File map

Cross-core synchronisation

The capture and render tasks share state through a single FreeRTOS queue of AudioChunk items (length 2). The capture side uses non-blocking xQueueSend; on a full queue it discards the oldest pending chunk and re-sends. This keeps I2S DMA running at hard real-time even if the FFT/render side stalls briefly (e.g. during the WS2812B frame flush), at the cost of occasionally dropping a chunk under sustained backpressure — strictly preferable to letting the DMA descriptors overflow.

There is no shared mutable state between cores beyond that queue. The render task owns the rolling 2048-sample buffer, the per-band decay state, and the LED framebuffer; the capture task owns only the I2S DMA and the int16 shift.

DSP constants

All knobs live as constexpr in config.h and are carried over byte-for-byte from the Raspberry Pi proof of concept (visualizer.py):

Build & flash

cd Firmware/ESP32Firmware
pio run -t upload
pio device monitor

The platform line in platformio.ini points at the pioarduino fork, which ships Arduino-ESP32 v3.x with the ESP-IDF 5.x i2s_std driver and the bundled esp-dsp component — both required by this firmware.

Bill of Materials (Abridged)

Roadmap

• Software proof-of-concept on Raspberry Pi 4
• FFT pipeline: I2S capture → Hanning → 2048-pt FFT → log bands (RMS-sum power) → dBFS + EQ → peak-bar decay → LED output
• Standalone button control with software debouncing
• Controller board schematic and layout (2-layer)
• LED matrix board schematic and layout (4-layer)
• PCB fabrication and bring-up
• Firmware ported to ESP32 with dual-core task allocation (capture on core 0, DSP+render on core 1, ESP-DSP FFT, FastLED render)
• Firmware tuned and validated on the ESP32-S3 controller board (re-pin I2S/LED data lines for the production layout)
• Enclosure design (Fusion 360) and 3D print
• Final integration, calibration, and enclosure fit

References

• Espressif ESP32-S3 Hardware Design Guidelines
• ICS-43434 Datasheet — InvenSense / TDK
• WS2812B Datasheet — Worldsemi
• USB Type-C Cable and Connector Specification — USB-IF