PD9823

LED cubes are really nothing new, many of us consider the building of a good sized one almost an electronics rite of passage that not so many manage to find the time or have the skill to pull off. It’s our pleasure to draw your attention to a lovely build, showing all the processes involved, the problems and the solutions found along the way.

Building a small cube is somewhat of a trivial affair, especially without considering PWM colour mixing, however as simple maths will illustrate, as you increase the number of LEDs on each side, the total number will quickly get quite large. More LEDs need more power and increase control complexity considerably. A larger matrix like this 16 x 16 x 16 LED build, has a total of 4096. This would be a nightmare to drive with plain RGB LEDs, even with cunning multiplexing, but luckily you can buy indexable LEDs in a through-hole package similar to the ubiquitous WS2812-based SMT LEDs you see around. These are based on the PD9823 controller, which can be programmed as if they were a WS2812, at least according to this analysis. Now you can simply chain a column of LEDs, with the control signal passed from LED to nearest neighbour.

Early on in the video build log, you will note there are four power supply modules needed to feed this juice. If we assume each LED consumes 60 mA on full-white (the data for this product link shows a peak value of 100 mA) that is still a total of 246 A or around 1 kW of power. The video does shows a peak power measurement of around this figure, for the whole array on full white, so the maths seems about right.

Control is via a Teensy 4.0 using the FlexIO function of the IMXRT1060RM CPU, and a bunch of 74AHCT595 shift registers giving 32 channels of up to 1000 LEDs per channel if needed. Roughly speaking, using the DMA with FlexIO, the Teensy can drive up to 1 Million LED updates per second, which works out about 32 channels of 100 LEDs per channel updated at 330 frames/sec, so plenty of resource is available. All this is with almost no CPU intervention, freeing that up for handling the 2.4-inch LCD based UI and running the animations, which looks pretty darn slick if you ask us. You can checkout the description of the firmware in the firmware section of the GitHub project. 3D printed jigs allowed for bending and clipping the LEDs leads as well as fixing and aligning the LED column units, so there really is enough detail there to allow anyone so inclined reproduce this, so long as you can swallow the cost of all those LEDs.

For a different approach to LED cubes, checkout this sweet panel based approach, and here’s a really small 4x4x4 module for those with less space to spare.

Continue reading “Big RGB LED Cube You Can Build Too” →

ws2812 and clones timing

It seems like every third project on Hackaday uses WS2812 RGB LEDs in some way. We all love our blinkenlights, and bright, cheap, serial controlled RGB LEDs are the bees knees.

As with all products these days, competing manufacturers have discovered the huge market for these things, and clones are now available. [Tim] recently took a look at the PD9823, as well as three versions of the WS2812. [Tim] is considered something of a WS2812 guru here at Hackaday. You might remember him from his WS2812 driver optimization article, which should be required reading for any WS2812 hacker.

As many of us know, the timing characteristics for these LEDs can be a pain to work with. The values also differ between the WS2812S and WS2812B. [Tim] discovered that the new through hole WS2812D parts are different yet again, though rather close to the B parts. The PD9823’s designers must have studied the WS2812’s closely, as their 190ns time base falls directly between WS2812S 166ns time and the 208ns time of the WS2812B. The PD9823 also requires a slightly longer reset pulse.

The takeaway is that well written drivers such as [Tim’s] should have no problem with the new parts, but compatibility is something to keep in mind as more clones hit the market.