Resound — Music-Reactive LED Subsystem (future) & Feasibility
Status: future/proposed. TL;DR: feasible, but use APA102/SK9822 (clock+data SPI), not WS2812, drive from the SINK (or a dedicated ESP32-C3), cap brightness ~25% on a switchable rail. Done that way it costs little CPU and tolerable battery; the naive way (WS2812 on a broadcaster) will glitch the audio.
1. LED hardware
APA102 / SK9822 (strongly recommended over WS2812B/SK6812). Decisive reason: the audio boards run the BT controller (Core 0, pri 23) + I2S DMA. WS2812's hard ~1.25 us/bit one-wire timing gets corrupted by BT/I2S ISRs (documented FastLED/WLED flicker), and a tight WS2812 ISR can starve the audio. APA102 is self-clocked over SPI+DMA — if the CPU is late the clock just pauses; data integrity preserved. Bonus: ~20 kHz PWM (no strobing in peripheral vision while riding) and a per-LED 5-bit global-brightness field for current capping. (SK9822 ~= APA102, often cheaper.)
Count: 8-16 (small) / 30 typical, 60 ceiling (beast). Voltage/level: run APA102 directly off the 3.7-4.2V battery rail -> 3.3V GPIO drives it with no level shifter (accept modest brightness/white-balance hit) — simplest. Or 5V + a 74AHCT125 buffer on CLK/DATA for max brightness. GPIO: a hardware SPI (e.g. GPIO13=MOSI/DATA, 14=SCK/CLK). Bus: dedicate LED_DAT + LED_CLK (+ switchable LED_VBAT_SW + GND) on the stacking connector; series 33-100 R on CLK/DATA at source.
2. Power impact
Per LED @5V: full white ~50-60 mA (worst case); quiescent (IC on, LED off) ~0.6-1 mA; realistic animated avg ~10-20 mA.
| LEDs | Full white | ~25% cap (~15 mA) | quiescent |
|---|---|---|---|
| 16 | 0.96 A | ~0.24 A | ~13 mA |
| 30 | 1.80 A | ~0.45 A | ~24 mA |
| 60 | 3.60 A | ~0.90 A | ~48 mA |
Capped 16 LEDs (~1 W) adds ~10-20% pack to hold 12h — tolerable. Uncapped 60-LED full-white (~3.6 A) would dwarf the whole audio draw and halve+ the beast runtime. Mandatory: (1) firmware brightness/current cap ~20-30% (FastLED setMaxPower / APA102 global brightness); (2) switchable LED rail (high-side P-FET gated by the HUD) to kill quiescent draw and offer a battery-saver mode; (3) decouple generously, tap LED power before the audio regulators (470-1000 uF at the strip).
3. Music-sync feasibility
Broadcasters already run A2DP source + I2S + delay FIFO + I2C slave — loaded and latency-critical. Two risks: (A) DSP CPU/RAM — level/envelope/beat detection is trivial; a light 256-512pt FFT is moderate but competes with BT on Core 0 + adds RAM where BT already dominates. (B) LED output timing — the real WS2812 failure; APA102+SPI/DMA eliminates it both ways.
Where to drive: NOT a broadcaster (most loaded/critical). SINK (has master PCM, less loaded) on a low-priority Core-1 task doing envelope/beat -> SPI/DMA to APA102 = the recommended baseline (genuinely safe). For FFT/fancy or guaranteed isolation, add a dedicated ESP32-C3 that just reads a level (I2C/I2S) and drives the LEDs.
Verdict: envelope/beat on the SINK + APA102 = safe. Light FFT = stretch goal, validate no audio dropouts first. WS2812 on any audio board = no.
4. BOM (LED option)
APA102C/SK9822 strip (16/30); optional ESP32-C3 (isolation/FFT); 74AHCT125 or 74LVC2G34 (only if on 5V/long runs); high-side load switch (AO3401 / TPS22xxx) for LED_VBAT_SW; 33-100 R series x2; 470-1000 uF bulk at strip; 0.1 uF locals; connector pins LED_DAT/LED_CLK/LED_VBAT_SW/GND.
Sources
WS2812B/SK6812 datasheets + power calcs; APA102/SK9822 analysis (cpldcpu, SparkFun); FastLED issues #1846/#719/#1438 (WS2812+BT/RMT corruption); ESP32 dual-core / BT core-pinning; esp-idf-lib SK9822/APA102 SPI driver.