RGB display development

[SeBsZ] tipped us off that he’s working on a display using RGB LEDs. He’s etched some nice surface mount controller boards to carry the ATmega8 microcontroller and NXP PCA9635 drivers. This setup uses the I2C bus to address each expansion board of 5 LED modules. Theoretically this hardware would allow for 638 RGB modules but because of power and refresh rate issues he’s set his sights on reaching somewhere between 100-125, a total of about 25 expansion boards.

There’s not a ton to show off yet. But we expect big things from the project. Partly because one of his goals is to generate a display that can be rolled up and easily moved, and partly because his large-scale light bulb displays are so impressive. Take a look at the video of his 60-bulb unit after the break.

11 thoughts on “RGB display development

  1. I recognize these chips. ;) Used them awhile back to also create a lighted sign, though no scrolling display. The sign consisted of 4 letters total (around 2 x 3 feet in size) populated with 20 – 30 RGB LED triplets (we could only find bulk LEDs at a reasonable price). Each letter was on a separate chip with an RGB channel for each letter.

    Excellent work! I’ll have to get the design docs and build posted when I get some time.

  2. I can’t believe that I can’t find this PCA9635 IC anywhere to buy except on digikey – they kill on delivery costs!
    any other sources?

  3. Hello all,

    Thanks for featuring my project. I got all my components from Digikey. There was free shipping over 40 Euros at the time. Don’t know if that’s still true now.

    If there are any questions feel free to ask :)


  4. I think that only NXP has the worst ordering options for their components.
    It’s like they are obsolete, but no they are not.

  5. Hi AO,

    I looked at the ShiftBrites, and while they essentially do the same thing as my LEDs (Change color), the working is fundamentally different. ShiftBrites, as the name implies, need to have serial data shifted through each ShiftBrite. This means for example if you have 100 ShiftBrites, to update the color of just 1 LED, you need to reshift the bits for each ShiftBrites. This takes time and is fundamentally slow.

    Using the NXP chips I’m using, there is one I^2C bus which connects to all the NXP chips. First of all, a single NXP chip handles 5RGB LEDs, instead of just one with the ShiftBrite. Secondly, since there is one bus and each NXP chip has a unique ID, I can change LEDs just by calling out the ID of the chip and then sending the RGB values. This means that if the display gets larger, updating single LEDs will never get slower. OF course, updating the entire display will get slower as the display gets larger (this is always the case).

    Finally, cost. A single ShiftBrite costs $5. This means that for my display of 100 RGB LEDs, using ShiftBrites would cost me $500. My components did not cost as much, not much less though, to be honest. The actual cost I will post on my blog sometime once I get all my bills together.

    I am glad you are liking my LEDs, this post might have come across in the wrong way, like I am not liking ShiftBrites. WHile I have never used them, I can see how they would be fantastic to use when you need just a couple of RGB LEDs. I was merely comparing them to my solution, as you had asked :)


  6. @SeBsZ: thanks for the extra info. I hadn’t imagined you had anything against ShiftBrites, I only wondered if you were “reinventing the wheel”, so to say. Individual update speeds for larger displays via I^2C vs shifting makes sense. Looking forward to more updates on your project!

  7. Thanks for your kind words. I have a huge update to post on my blog sebsz.com tomorrow, please check it tomorrow if you are interested. I have finished a small board with 25 RGB LEDs, I’m extremely happy with the result.

  8. Yeah, the speed of updating ShiftBrites does depend a lot on how you plan to use them. Each module needs 32 bits, on a 255 device chain your update speed with a 4MHz shift clock is about 490 times per second. In reality, you get about 150 updates per second and most of your CPU time is used calculating color effects rather than sending the data. On the AVRs and Arduinos the hardware SPI peripheral works really well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s