One tower of a planned 16x16x16 LED cube

Oct 10, 2026 Last reply: 8 hours ago 2 Replies
Jump to replies (2)

Scaling a hobby cube up to a full 16x16x16 matrix is a problem most people never get past, and the maker attacked it one tower at a time. Each tower holds 4096 LEDs soldered into a tall vertical grid, mounted on a black base, and sixteen of them together make the finished cube. Life circumstances put it on hold with fifteen towers still to go, though the plan is to resume when things allow.



The electronics are where this gets serious. Each PL9823 LED has power, ground and data pins instead of RGB pins, and being digital allows more color and brightness flexibility. A single I/O port on a Teensy 4.0 pushes the data, with four 8-bit shift registers alongside, and the LEDs run in 32 parallel channels so they never fry. Four 300-watt supplies connect in parallel with a wall plug, and a distribution system feeds every channel equally so no tower ends up dimmer. The board came from KiCad and JLCPCB, the code is C++, and the structure is 3D printed.



The animations lean on Quaternions, a four-dimensional quantity that fits three spatial dimensions plus time, and the chip clock was retuned to time data across channels with microsecond precision. Animation data needed decomposing and reordering to run as parallel streams instead of series. There are around ten animations, including rain, the earth and a water-droplet effect, plus other physics-based ones. Printed jigs handled LED placement, wire cutting and pin bending, clamps held each lattice at correct spacing, and coiled wire was straightened in a drill. Flux went on every single joint.



Not everything is settled. Actual draw at full brightness has never been measured, and the maker suspects the supplies were over-specced. Several board revisions failed when high-frequency data induced current and scrambled the signal; the fix was a scatter of tiny holes, and finding it was rough without formal electronics training. At full white the tower is blinding, which says plenty on its own.


One thing I keep wondering about: with 32 parallel channels fed from a single I/O port, how did the maker keep the data arriving in step across all of them? Was that purely the clock retune, or did the shift registers handle part of the timing too?

The maker covered part of that. The chip's internal clock got retuned so data could be timed across channels with microsecond precision, and the animation data itself needed decomposing and reordering to run as parallel instead of series. How the shift registers fit into the timing side has not been said.

Join the Discussion

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

Didn't find your answer?

Ask the community — no account required