Hardware · Discipline
Lighting
Getting DMX out of a network and onto a truss without a cable per box.
Lighting data is the easiest protocol problem on this site and one of the more annoying physical ones. Art-Net and sACN are well documented, RDM is well documented, and none of that helps when the node on the truss needs its own power drop and its own home run to the switch, times fourteen.
So the interesting decisions in a DMX node aren't about the protocol at all. They're about how many cables it takes to add one, what happens when somebody stands on an XLR, and whether discovery blocks the web interface while it runs.
1 board · none fabricated yet
Lighting · Art-Net / sACN to DMX512
nanODE
Board v0.4.1 · routing in progress
A PoE-powered, daisy-chainable Art-Net / sACN to 4x DMX512 node. One Cat5 in and one loop out, carrying power and data, so a run of nodes needs a single cable from the switch instead of one per box.
- 4 universes out5-pin XLR, from Art-Net 4 (including ArtSync) or sACN / E1.31.
- Real RDM discoveryRuns as a background task, so the web console never blocks on it.
- Daisy-chain built inInternal 3-port switch: Cat5 in, loop out, plus the ESP32 itself.
- Field-replaceable portsEvery external connector is a daughter-card. Smash an XLR on site, swap it without a soldering iron.
- Browser consoleOver WiFi or Ethernet: patch, address, and see RDM devices live.
Where it stands
The firmware builds clean against real ESP-IDF 5.5 tooling, and the REST API and RDM discovery are verified against a mock node. But it has never run on real silicon, and the board render is older than the current layout.
- MCU
- ESP32
- Network
- Internal 3-port switch, PoE
- Outputs
- 4 x DMX512 on 5-pin XLR
- Protocols
- Art-Net 4, sACN / E1.31, RDM
- Enclosure
- Aluminium extrusion, laser-cut acrylic ends
- Repo
- Private
One cable per run, not per node
A node with an internal three-port switch (in, loop out, and the processor itself) turns a row of boxes into a single cable from the switch, carrying both power and data. That's the reason the board exists, and the same thinking treats the connectors as consumables: every external connector is a daughter-card, so an XLR that gets smashed on site is swapped without a soldering iron.
RDM discovery runs as a background task for a related reason. A discovery sweep is slow, and it's always the moment somebody's standing at a laptop wanting to re-patch, so it mustn't block the console it's running behind.
How far it's got
The firmware builds clean against real ESP-IDF tooling, and the REST API and RDM discovery are verified against a mock node. But this has never run on real silicon, and the render on the page is older than the current layout. Treat every performance claim as what the design is aiming for, not something that's been measured.
The lighting design tools that do exist, and have been used, are software: coverage and pixel-map calculators, and the MVR/GDTF plumbing behind them.
Related, elsewhere on the site
The whole bench
This is only one corner of it
The hardware index has every board on one page, and you can filter it by discipline: lighting nodes, audio boxes, video processing, the physical layer under all of it and the RF work on top.