LED Cube Noob

Forum 2005-2010 (read only) Hardware Interfacing
1

Hi all, I've been threatening to add electronics to my list of hobbies for several years now. I stumbled across someone's LED cube on the 'Net early last week, and that sealed the deal for me. I read enough to learn that I wanted to go with an Arduino controller because you guys and your projects are awesome, so I have one en route to begin tinkering with.

I've actually read every blog and forum post on the topic that I can find, (some several times)? I think I know enough to at least ask some basic questions and have most of the vocabulary in the right spot, so I was wondering if someone might be willing to mentor me a little. I'd like to get enough knowledge into my head to ultimately build a 9x9x9 RGB cube (I really wanted a central axis + decent resolution is the reason for the odd number). I'm a realist though, and goal 1 will be to get one RGB LED lit up! Then try to work my way up to a 3x3x3 most likely.

I now understand the concept and benefits of muxing, and think it's brilliant. I believe that one of the first blogs I came across was using common anodes on each layer, single-color LED's, and was individually controlling each column's cathode, so at any given instant, only one LED is lit. Given a high enough refresh rate, it plays on the eye's POV to give the illusion of multiple (even all) LED's being lit.

Then I came across the concept of bit shifting? Serial In, Parallel Out. And then LED drivers like the TLC5940. If I have my concepts down correctly, the TLC5940 is basically a task-specific shift register and can drive N*16 channels in parallel, correct? Since I had the “one LED on at any given time” logic still in my head, I was having a hard time understanding the need for boosting the current to the LED's when folks were using the TLC's. I think I'm past that, but want to be sure I am truly following what's taking place.

In high level terms, it is now my understanding that the controller would basically be sending an entire layer's instructions (1 “frame's” worth of data) all at once, and the TLC(s) dissect that into relevant channel data and drive the LED's for 4096 cycles, aka PWM right? In the case of an RGB LED, the length of time that each component color was instructed to stay on during these 4096 cycles would control both the perceived color and the brightness.

So in thinking about my 9x9x9 (I know, I need to get 1 lit first, but I'd like a little better understanding of what I'd be working towards!), I would be potentially lighting 81 RGBs (243 distinct channels) at any given time and would need 16 TLC's to make that happen.

That brings me to the area I'm having trouble wrapping my head around. If my math is right, for 20mA LED's, that would potentially be 1.62 amps? From what I've gathered, in this situation, the 5940 is instead used to toggle a transistor or (I've dabbled with transistors in the past and have a general understanding, but haven't quite figured out how a mosfet is different) which in turn switches a high power circuit on/off. I'm struggling with learning how to do the calculations necessary to size things properly at this point, and honestly, which way to build it. The general consensus seems to be that mosfets are preferable in this situation. Mike uses p-channel mosfets in his cool mini monome. Vespin used p-channel's in his RGB cube but if I read correctly he was getting “layer ghosting” that he was attributing to the p-channels and was going to redeploy with n-channels, but I wasn't able to find any outcome of that.

I have a bunch of 20mA, common anode, “2.5 ~ 3.2V” cheap RGB LED's on the way and would like to be able to work my way up to driving “many” on a breadboard or two for testing/learning. I'm pretty convinced that the TLC5940 is going to be in my ultimate solution so I was going to go ahead and order a few to tinker with. I'd like to order some potential parts for various high power circuits to work with, but if it wasn't clear in the previous paragraph, I'm lost. Any advice (for someone who's out on the fringe of comprehension) on coming up with a parts list for that part of the circuit, given “x” LED's being driven?

Many thanks for your time & knowledge!

2

I'm basically at the same place you are. I'm trying to figure out how many transistors are needed if any and how they are setup in a shift register based LED Cube.

Do I need a separate power supply for the transistors or can I suck that out of the Arduino? Does the Arduino need to be plugged into the wall or does a 9v battery or USB connection provide enough power?

3

So in thinking about my 9x9x9 (I know, I need to get 1 lit first, but I'd like a little better understanding of what I'd be working towards!), I would be potentially lighting 81 RGBs (243 distinct channels) at any given time and would need 16 TLC's to make that happen.

I think you need to check your sums 9X9X9 RGB LEDs is a total of 2187 LEDs controlled by an arduino, that unfortunately is never going to happen.
There is a limit to the amount of multiplexing you can do because the more you switch the less total time any one LED has on at any instance and so the dimmer it is. I would not push it greater than a factor of 4. Also as you get more TLC5940s it takes longer to load them for each multiplex slot. In the end the rate goes down an the whole thing starts to flicker.
Yes you will need an external PSU and FETs to drive them. While I haven't read that article you sited layer ghosting will not be a function of what type of FETs that were used it will be due to faulty design of either the hardware or the software. Basically to use N channel FETs for high side driving is not a very good solution because you are forced to have a secondary driver (extra transistor or FET) or you end up shunting large amounts of current to ground through small value drain resistors. The FETs I used are cheap and can switch up to 4A but they are surface mount and tricky to solder on strip board. Look for a good logic level FET and you should find on at less than the $0.50 mark.

Good luck.