Camera Board Maps A Knotted LED String Automatically

Oct 14, 2026 Last reply: 6 minutes ago 3 Replies
Jump to replies (3)

The most surprising part of this build is that a tangled bundle of fifty WS2811 LEDs can work out its own physical layout. Atomic14 pointed an ESP32-CAM board at the jumbled string and let the hardware figure out where every light actually sits. Calibration starts with a dark baseline frame, then each LED is lit one at a time and another frame is captured. Comparing the frames gives the 2D coordinates of every light on the string.



The electronics are refreshingly simple. Everything sits on a solderless breadboard with jumper wires: an FTDI board for programming, two micro-USB power breakouts, a pair of electrolytic filter capacitors plus a small decoupling cap, and a TC4469 MOSFET driver acting as a 3.3V-to-5V logic shifter. The ESP32 also hosts a web interface with Clear, Calibrate, Pause, Run, Show Locations and Grab Frame buttons, and all the code lives in a public repository.



Once calibrated, a virtual 2D frame buffer is sampled at each detected coordinate, and the mapped array drives multi-color animations. The maker works with tiny 160x120 pixel images and reports the system performs surprisingly well for simple geometric patterns, which matches my own view that the results look far tidier than a knot of wires has any right to.



There are honest rough edges. One LED in the string is dead, initially mistaken for a calibration miss, and the maker notes a fifty-LED string has a good chance of containing a dud. The LED count is hardcoded in the ESP code for now. A planned rickroll animation also fell flat because fifty lights is not enough for it, though permission has been secured to buy more LEDs for a very ambitious Christmas tree display.



Project by atomic14. Watch it on their YouTube channel:

formatting link


The TC4469 choice stands out to me. Repurposing a MOSFET driver as the level shifter is a neat trick, and it seems a smart call since those chips are cheap, easy to find and handle the 3.3V to 5V jump without fuss. I would guess it also drives the LED data line more firmly than a simple transistor arrangement would, though that is just my reading of the parts list.

I am curious how the calibration copes with the dead LED. When each light is switched on individually and the frames are compared, does the dead one simply never show up as a detected coordinate, or does it get mapped to a wrong spot? And does the hardcoded count need adjusting to account for it?

Making the LED count a setting in the web interface rather than a hardcoded value would be my first suggestion. Then anyone could swap in a different string length and recalibrate without touching the code, which matters if more LEDs are coming for the Christmas tree build. A count check against detected positions could even flag dead lights automatically during calibration.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required