Wireless RGB Lighting Control System

Jul. 2025 - Sept. 2025

Designed and implemented a BLE-based wireless RGB lighting control system during an internship at NZXT, coordinating two RGB peripherals from a single central controller while investigating EMI/RFI performance inside a PC enclosure.

Embedded Systems BLE Firmware Arduino EMI/RF Measurement Hardware Design

Back to Portfolio View Technical Report View Presentation

Wireless BLE RGB lighting control system prototype inside a PC case

Project Overview

During a summer internship at NZXT, I designed and implemented a proof-of-concept wireless RGB lighting control system using Bluetooth Low Energy (BLE). The system uses a central Arduino Nano 33 BLE to coordinate two independent RGB peripherals—an SK9822 LED strip and a set of NZXT F420 RGB fans—entirely wirelessly, enclosed inside a PC case. In addition to building the prototype, I performed RF measurements to characterize the electromagnetic environment inside the chassis and authored a report recommending next steps for NZXT to evolve the prototype into a manufacturable product.

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
No prior internal data existed on how BLE performs in this environment or what interference the wireless system itself introduces

System Architecture

Central Controller: Arduino Nano 33 BLE (nRF52840) — manages BLE connections, generates RGB frames at 60 FPS, and cycles lighting modes via a button interrupt
Peripheral 1 — LED Strip Controller: Arduino Nano 33 BLE — receives RGB data and commands over BLE, drives a 100-LED SK9822 strip via SPI with a 3.3V→5V level shifter
Peripheral 2 — UART Bridge: Arduino Nano 33 BLE — 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 — toggled by a button on the central
RF Measurement: nRF52840 USB Dongle + RSSI Viewer, scanning all 40 BLE channels at 10 ms intervals — tested across four positions inside and outside the case

Key Technical Decisions

Chose SK9822 (SPI-compatible) over WS2812B for the LED strip — the Nano 33 BLE cannot sustain the 800 kHz, 1.25 µs-per-bit WS2812B waveform due to Mbed OS interrupt jitter and slow GPIO (~32 kHz max toggle rate)
Added a Raspberry Pi Pico as a timing coprocessor for the RGB fans, which require the WS2812B protocol — the Pico generates the precise waveform while the BLE system handles wireless coordination
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 (quietest baseline)
3 inches above GPU: avg −85.9 dBm (~6 dB noisier than outside)
Directly on GPU: avg −83.9 dBm (GPU switching circuitry identified as a major RF noise source)
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 — antenna placement and efficient transmission patterns are critical

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 (ArduinoBLE / Mbed Cordio enforces a 2–3 connection limit)
Intermittent ~4-second freezes observed during continuous streaming — traced to ArduinoBLE library thread blocking or Nordic SoftDevice radio calibration cycles, not fixable at the application layer
Both peripherals fully enclosed inside the PC case during all demonstrations

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 (ble_dual_central.ino), LED strip peripheral (ble_led_strip_display.ino), and UART bridge peripheral (ble_to_uart_bridge.ino)
Implemented a custom SPI driver for the SK9822 LED strip (BGR color order) and coordinated it with BLE characteristic writes
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, analyzed results, and drew design implications
Authored a full technical report covering theoretical analysis, proof of concept, measurement findings, and short/medium/long-term 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