Project Logs

Collapse

• The LumiBand app - BLE control, animations, and the joy of app store approvals

  Markus Loeffler • 6 days ago • 0 comments

  Every hardware project eventually needs an app. LumiBand is no exception, the Gen3 uses BLE for setup and control, which means someone has to write the software side. That someone was me.

  What the app does The LumiBand app is built in Flutter, which was the right call for a solo developer needing iOS and Android from a single codebase. It handles four main functions:

  • BLE device pairing: scanning for nearby LumiBand wristbands, connecting, and managing multiple devices simultaneously. In a festival environment you might be pairing up to 6 units before a show, so the UX needed to be fast and reliable.
  • DMX addressing: assigning each wristband a DMX universe and start address directly from your phone. No laptop, no physical connector, no pulling wristbands off people's wrists. Ten seconds per unit via BLE. Once set the address persists on the device.
  • Animation control: selecting and triggering pre-built animations that react to sound directly from the app over BLE.
  • Live color and pattern editing: building your own visual style in real time and pushing it to connected wristbands instantly.

  App Store status iOS version is live on the App Store now, Apple's review process was straightforward for a BLE hardware companion app. They came back with an ask to record the app pairing with the actual wristband.

  Android is a different story. Google Play requires a mandatory closed testing period of at least 14 days with a minimum of 12 active testers before granting production access. The app itself passed review - it's purely a process gate. Currently recruiting Android testers to complete the requirement.

  If you have an Android device and want early access to the LumiBand app, drop a comment below :: looking for testers right now.

  Screenshots in the gallery above show the device pairing flow, basic modes, playlist, and animation editor.

• GATT API — control LumiBand from anything with BLE

  Markus Loeffler • 05/02/2026 at 10:03 • 0 comments

  One of the goals from the start was to make LumiBand an open platform. The firmware exposes a single custom BLE service with six characteristics that let you drive the band from any language or tool that speaks BLE. 

  What you can control

  Everything the companion app does is available over GATT:

  • Solid colour + strobe — set R/G/B/brightness in one write, with an optional strobe byte (0 = steady, 1–255 = speed, logarithmic scale)
  • Master brightness — a dedicated single-byte characteristic so you can dim/brighten without touching the current colour
  • Built-in presets — Classic (sound-reactive with beat detection), Static, Party, Lava, Dim — one byte each
  • Custom effects — up to 8 uploadable animation slots, each a grid of up to 8 rows × 15 LEDs with per-effect timing, loop mode, and sound-reactive settings. A chunked upload protocol lets you push new animations over BLE in a few hundred milliseconds
  • Playlist mode — queue any combination of custom slots with a configurable interval; the band cycles through them automatically
  • Super-saver mode — blanks every other LED to halve power draw, useful for long performances
  • Multi-device clock sync — write a shared 32-bit timestamp to all bands simultaneously and they lock to the same animation frame, regardless of when each one connected
  • Status notifications — subscribe once and get pushed updates whenever mode or brightness changes; no polling needed
  • Battery level — standard Bluetooth Battery Service (0x180F), recognised automatically by nRF Connect, LightBlue, and most BLE tools

  
  

  OTA firmware update

  The nRF52832 build now also exposes the Nordic DFU service alongside the app service. Point nRF Connect at the band, select the .zip the build produces, and the bootloader handles the rest — no cable, no programmer.

  Open spec

  The full command reference, upload protocol, and working examples in Python, JavaScript, Swift, Kotlin, and QLC+ are in the GIT-repo under tools/lumiband-gatt/. If you build something with it, let us know.

• Switching from ESP32 to nRF52840 — and why WiFi had to go

  Markus Loeffler • 04/24/2026 at 06:41 • 0 comments

  The ESP32 was the obvious choice for wireless DMX reception, native WiFi, Art-Net/sACN support, done. But obvious isn't always right.

  Running WiFi on a wristband is brutal on battery. We measured roughly 10x the power consumption compared to BLE. On a single cell LiPo that's the difference between a 6 hour festival set and a 45 minute demo. Not a trade-off we're willing to make.

  So WiFi is gone from the wristband itself. The nRF52840 handles everything over BLE - it's leaner, better suited for a wearable, and the RF performance is excellent in dense crowd environments where you have hundreds of devices competing for airspace.

  The DMX side is solved with a WiFi-BLE bridge sitting outside the wristband, a small fixed node that receives Art-Net or sACN over WiFi from the lighting console and rebroadcasts to the wristbands over BLE. The wristband stays dumb and power-efficient. The bridge handles the heavy lifting.

  New addition: VEML6040 RGBW color sensor

  Added a VEML6040 ambient light sensor to the board. I have a specific application in mind for live events that I'm not ready to share publicly yet - but if you've ever thought about what a wristband could do if it knew what color light was hitting it from the stage rig, you're probably on the right track.
  More on that when the time is right. Follow the project if you don't want to miss it.
  Next log: nRF52840 RF layout decisions and BLE performance in high-density environments.

  See the PCB below, going to small batch manufacturing now

  Check out the Kickstarter
  

• From ATtiny85 + bare mic to ESP32 + wireless DMX — what changed

  Markus Loeffler • 04/13/2026 at 13:01 • 0 comments

  Gen2 was intentionally dumb. ATtiny85, 15 NeoPixels, electret mic wired straight into the ADC with no amplifier circuit. It worked because festivals are loud — the venue provides the gain. Aggressive brightness capping got 6 hours out of a single cell LiPo.
  The limitation was autonomy. Every wristband made its own beat detection decision independently. Close enough to look coordinated, but not actually synchronized.
  
  Gen3 solves this by making the wristband a proper DMX fixture. The ESP32 connects to a WiFi network running Art-Net or sACN and takes its cues from the lighting console. Every wristband fires exactly when the operator says so, in whatever colour and pattern they program. The crowd becomes an extension of the stage rig.
  BLE handles setup. Assigning a DMX universe and start address to a wristband takes about 10 seconds from a phone — no laptop, no physical connector, no pulling units off wrists. Once set it's persistent.
  The mic input stayed. If there's no DMX network available the wristband falls back to autonomous mode. Same 90dB+ threshold tuning as gen2. Belt and suspenders.
  Next log: PCB layout decisions and why RF decoupling on the ESP32 is less forgiving than the datasheet implies.

View all 4 project logs