Why ATmega2560, not ESP32/Pi: WS2812B addressable LEDs need microsecond-precise bit-banged timing on the data line. Any platform running an OS or wireless stack (FreeRTOS on ESP32, Linux on Pi) can introduce scheduler/interrupt jitter that corrupts that timing mid-frame. The 2560 runs bare-metal — no radio, no scheduler — so the signal stays clean by construction, not by careful workarounds. It also runs native 5V logic, matching WS2812B's data voltage directly with no level-shifting required, and its 86 GPIO pins let all 187 LEDs be split into 8 parallel chains driven simultaneously off a single AVR port (PORTA), keeping every chain in lockstep with minimal firmware overhead.

Why external 5V supply, not onboard buck conversion: At worst-case full-white brightness, 187 LEDs draw upward of 11A — far beyond what fits cleanly on a 2-layer board alongside 187 densely-packed components and 8 parallel data chains. Rather than compromise trace routing and thermal management to squeeze buck conversion onto the LED PCB itself, power regulation is offloaded to a dedicated external 12V-to-5V module. This keeps switching-regulator noise physically separated from the timing-sensitive data lines, and keeps the LED board itself simple: just power in, data out.

Why UART, not standalone/WiFi control: V1 is designed to be driven externally — over serial, from a PC, a companion microcontroller, or paired hardware — rather than carrying its own onboard control logic (buttons, sensors, wireless). This keeps the board's one job (drive 187 LEDs cleanly and precisely) uncomplicated, while leaving the door open for smarter control (audio-reactive, ambient-light adaptive, standalone modes) to be added in later hardware revisions without touching the core LED driving design.