Wireless RGB Lighting Control System

Project Overview

The Problem

• Current NZXT RGB peripherals require wired data connections to the motherboard, occupying headers and adding internal cable clutter
• A wireless approach offers increased flexibility and cleaner builds, but PC enclosures are a challenging RF environment
• The metallic case creates a Faraday-cage effect, trapping internal noise from GPUs, PSUs, and other switching components

System Architecture

Central Controller

Arduino Nano 33 BLE (nRF52840) that manages BLE connections, generates RGB frames and cycles lighting modes via a button interrupt

Peripheral 1 — LED Strip Controller

Arduino Nano 33 BLE that receives RGB data and commands over BLE and drives a 100-LED SK9822 strip via SPI with a 3.3V→5V level shifter

Peripheral 2 — UART Bridge

Arduino Nano 33 BLE that receives BLE data and forwards it over UART to a Raspberry Pi Pico, which generates the WS2812B timing-critical signal for RGB fans

Lighting Modes

RGB Live (continuous 19 Hz frame streaming) and four command-based presets (Rainbow, Theater Chase, Color Wipe) which can be toggled by a button on the central

Key Technical Decisions

• Chose SK9822 (SPI-compatible) over WS2812B for the LED strip because reliable WS2812B bit-banging on the Nano 33 BLE is blocked by SoftDevice interrupt preemption, and Arduino doesn't expose the nRF52840 hardware peripherals (PWM+DMA, I2S) that would generate the waveform independently of the CPU
• Added a Raspberry Pi Pico as a timing coprocessor for the RGB fans; the Pico generates the WS2812B waveform deterministically while the Nano handles BLE
• Used a star BLE topology over mesh — mesh adds overhead and broadcast complexity that is unnecessary for a PC-scale deployment of 2–3 nodes
• Implemented two operational modes — high-bandwidth Live RGB streaming and low-bandwidth command-triggered presets — to trade off flexibility vs. channel occupancy and RFI

RF Measurement Results

• Outside case: avg −91.7 dBm
• 3 inches above GPU: avg −85.9 dBm (~6 dB noisier than outside)
• Directly on GPU: avg −83.9 dBm (GPU switching circuitry results in more noise)
• Above GPU with BLE system active: avg −76.1 dBm (~10 dB increase over idle inside-case measurement)
• Conclusion: the case interior is measurably noisier, and the BLE system itself raises the noise floor. Kind of obvious!

Performance Results & Limitations

• Achieved ~19 Hz RGB frame delivery to two simultaneous BLE peripherals (vs. ~40 Hz with a single peripheral)
• Connection cap: attempts to add a third peripheral consistently failed. Nordic's SoftDevice firmware supports more concurrent connections, but ArduinoBLE doesn't expose the configuration to raise the limit

What I Did

• Designed the full hardware architecture: central controller, two BLE peripherals, level shifters, shared power and ground
• Wrote all firmware: central BLE manager, LED strip peripheral, and UART bridge peripheral
• Developed the WS2812B coprocessor flow on the Raspberry Pi Pico in CircuitPython, bridged from the UART peripheral
• Performed RF/EMI measurements using the nRF52840 dongle and RSSI Viewer across four test conditions and analyzed results
• Authored a full technical report covering theoretical analysis and research, proof of concept, measurement findings, and future recommendations for NZXT

Recommendations Delivered to NZXT

• Short-term: bypass ArduinoBLE and develop directly on the Nordic nRF Connect SDK for full control of connection interval, MTU, PHY, and TX power
• Medium-term: evaluate Bluetooth Mesh only if scaling beyond a single case; prefer command-triggered presets over streaming to minimize RFI
• Long-term: migrate to Nordic DKs or ESP32-class SoCs, integrate antenna placement into case design from the start, and schedule pre-compliance EMC testing (CISPR 32 / EN 55032) early

Some Lessons and Regrets