8x8x8 multiplexed LED cube with an Arduino Mega 2560

Can you add on to the 4x4x4 to expand it into the 8x8x8? If so, then you're already 25% done.

:slight_smile: I've thought of extending the 4x4x4 cube into an 8x8x8 one... but I've reached the conclusion that I'll start fresh with the big one. With the little one I've learned how to solder nd how not to solder the LEDs together, so it has some minor aesthetic flows. The big one is planned to be a work of art :slight_smile:

That would be great if you could put together a little document. I dont need source or price of parts, but listing the specific parts, and the specific calculations and schematics would be great.

Hey there, Hippynerd!

Here's the BOM that I've promised, in form of a Google spreadhseet:
https://docs.google.com/spreadsheet/ccc?key=0An4wEyr8LJXZdFR4MjhVXzNBZ2R3WWFkQzFYeWlCa0E&usp=sharing

I tried to make it as complete as possible, so there might be some things there that you don't need. The included prices are estimations of the prices that I have paid myself. My own total is 189$, but in reality it's probably 30% more because from several components I've bought more than needed, just to be safe.

I have bumped into a very interesting (and annoying effect) with the LED cube.

Let's say that we turn on one LED on the lowest anode plane, the corner LED which is leftmost and frontmost, like this:

    digitalWrite (PIN_SS, LOW); //Start transferring data

    SPI.transfer (B00000000);
    SPI.transfer (B00000001); //leftmost, frontmost corner cathode column
    SPI.transfer (B00000001); //bottom anode plane

    digitalWrite (PIN_SS, HIGH); //Done transferring data

Then we turn that LED off and instead we turn on another LED on the top layer, in the opposite (rightmost, backmost) corner, like this:

    digitalWrite (PIN_SS, LOW); //Start transferring data

    SPI.transfer (B10000000); //rightmost, backmost corner cathode column
    SPI.transfer (B00000000);
    SPI.transfer (B00001000); //top anode plane

    digitalWrite (PIN_SS, HIGH); //Done transferring data

The extremely strange thing that happens is that at the moment when we switch from the first LED to the second, for a very brief moment we can see a ghosting (a pale turn-on, but still visible) of a third LED, which is in the newly turned on anode plane but in the old cathode column, in other words in our example, the LED in the top plane, in the leftost, frontmost column.

This becomes very bothering as soon as we start using multiplexing (and that's the goal here). The way it manifests itself during multiplexing is that the image shown in the current multiplexed plane is ghosted in the previously multiplexed plane.

I can't find an explanation for this. It's like the cathode column that was turned on first is not turning off fast enough and when the second anode plane is turned on in combination with another cathode column, for a brief moment the intersection of the new plane and the old column is lit up. But why is the old cathode column not turned off fast enough? Could it be due to some characteristic of the TPIC6B595 shift registers? Some weird latency? Or maybe it's something related to how the data is pushed from one shift register to the next one?

I've tried CrossRoads' suggestion and separated the SS pin for the anode layers from the cathode SS pins. I turned off the anode planes first, then I set up the cathodes and finally I turned the anode planes back on. It doesn't help. The ghosting remains.

I got around the problem in the software by doing this: first I turn off everything by pushing all 0s into all shift registers, then I wait for 100 microseconds (1/10 milliseconds), after that I push the new data into all shift registers (including cathode and anode shift registers). This makes the ghosting go away by allowing the old cathode column to turn off before a new cathode column is turned on in a new anode layer. The only problem is that this approach introduces a barely noticeable tiny flickering in the LEDs when they are constantly on (through multiplexing). It's not a very big problem, because usually the LEDs won't be constantly on and the flickering is very hard to notice, but it still bothers me a little. And I'm curious what is behind that latency in turning off the cathode columns. I'm also worried that if this is somehow caused by some delay in the shift registers, the problem will be more severe in the 8x8x8 cube, where there will be 9 shift registers instead of the current 3 and the flickering will become more visible...

Try this: use the TPIC6B595 OE to disable the outputs when switching.

Use direct port manipulation to make it go faster.
So that OE is bit 2 and SS/Latch is bit 3, both on port D:

PORTD = PORTD | B00000010; // bring OE/ high
// xfer data
    SPI.transfer (B00000000);
    SPI.transfer (B00000001); //leftmost, frontmost corner cathode column
    SPI.transfer (B00000001); //bottom anode plane
PORTD = PORTD & B11111011; // bring SS/latch low
PORTD = PORDT | B00000110;  //  bring OE/ an SS/latch high

So... basically your are suspecting that the latency is introduced by the Arduino itself! Interesting thought!
Does this require any rewiring in the physical circuit? Do I need to connect anything from the Arduino to the circuit?

I've read about the direct port manipulation and I think I understand what it's about and I have also come to the understanding that OE means output enable. I'm still struggling to understand the following:

  1. Looking at the datasheet of the TPIC6B595, I can't find an OE pin on it. How can I set the OE on the shift register? My current understanding is that I should use two pins on the Arduino to control when and how data is transferred to the shift registers: SS and OE, instead of the currently used SS only. The SS should remain connected as it is now, but where on the shift registers is the OE pin?
  2. The direct port manipulation section of the Arduino documentation states that PORTD is mapped to pins 0-7, but they only say that it is so on ATmega8, ATmega168 and ATeega328 chips. Mine is ATmega2560. Nobody seems to write anything about which pins PORTD maps to on the Mega2560... I think I would have to disconnect the SS from the current Arduino pin 53 and connect it to where bit 2 of PORTD is mapped. I should connect the OE to where PORTD's bit 3 maps... But which pins are the bits of PORTD mapped to on my Mega2560? :slight_smile:
  3. There are a few things I'm not sure I understand in the example code:
PORTD = PORTD | B00000010; // bring OE/ high
// xfer data
    SPI.transfer (B00000000);
    SPI.transfer (B00000001); //leftmost, frontmost corner cathode column
    SPI.transfer (B00000001); //bottom anode plane
PORTD = PORTD & B11111011; // bring SS/latch low
PORTD = PORDT | B00000110;  //  bring OE/ an SS/latch high

a) PORTD = PORTD | B00000010; //bring OE HIGH
Didn't you mean to bring EO low here (in the beginning, before the SPI transfers)? Isn't the goal to disable the outputs during the next lines, which do the transfer?
b) PORTD = PORTD & B11111011;
PORTD = PORTD | B00000110;
There's nothing in between bringing the SS/latch LOW and bringing it back HIGH. Is that correct and is that so in order to keep the time between the point when the data transfer starts and the data transfer ends to a minimum?

Thank you!

I've found a good resource here: Electronics - Henning Karlsen
If you open the PDF that corresponds to the Arduino Mega 2560 Rev3, you'll see the port labels there. For example PORTD 0-3 is mapped to digital pins 18-21. I hope that's right. I don't exactly know which revision of the Mega2560 I have, but hopefully the Rev3 mapping will apply to my device too.

The sad conclusion is that if people will try to use my code on other type of Arduinos (not Mega2560), they'll have to figure out where PORTD is mapped on their device.

So now what remains to be figured out is what is OE on the TPIC6B595 shift registers and how I can control it. Also, the questions a) and b) referring to CrossRoads' example code still puzzle me...

OK, I have figured it out! OE (output enable) is pin 9 (marked G) on the TPIC6B595. So I disconnected the OE pins of the shift registers from the GND (that's how it originally was) and connected them in chain and to the Arduino pin 49. I left SS on Arduino pin 53, as it was before. And I started using this code:

    PORTL |= B00000001; //Output enable (pin 49) disabled
    SPI.transfer (cathodeData1);
    SPI.transfer (cathodeData2);
    SPI.transfer (anodeData);
    PORTB &= B11111110; //Latch (pin 53) low - start transfering data    
    PORTB |= B00000001; //Latch (pin 53) high - done transfering data
    PORTL &= B11111110; //Output enable (pin 49) enabled

Unfortunately this doesn't change anything :frowning: The ghosting remains. During multiplexing the ghosting is seen as the previous plane being lit up very lightly at the same time when the new layer is lit up at full brightness.

Yes G pin Output enable.
High is disabled, Low is enabled.
Might have to do some experimenting to find the best time to turn the outputs on & off.

Ports, PORTD was just an example, yes portability is reduced somewhat in exchange for speed.

Setting the SS pin Low/High back to back- all that is needed is rising edge to clock the bits into the output register, does not matter where it goes low.
Maybe add a pull down resistor on the anode layers to ensure they go low when their transistor is turned off.

CrossRoads, by adding pulldown resistors to the anode layers you meant adding some resistors between the MOSFET gates and the GND, right? I'm a bit confused by this (just like I was last time when you suggested it) because currently we have some pullups there (between the MOSFET gates and the 5V). I thought the role of the pullups was to ensure that the anode layers go low when the MOSFET is off... but now you suggested that we need pulldowns for the same purpose... I guess I'm missing something here.

What I am saying is leave the MOSFET gate alone and put a resistor from the LED Anode to Gnd - that will ensure the LEDs are being turned off when the MOSFET is off.

Right! I knew I was misunderstanding something :slight_smile: This sounds good. I'll try it tonight when I get home.
Thank you!

Unfortunately I still haven't had the time to try the pulldowns on the anodes (I suspect they wil actually be needed on the cathodes), I'll get back with my findings as soon as I'll be able to try it out.

In the meantime I wanted to share with you guys something that might be quite important. As I wrote earlier, modern LEDs might be rated at 20 mA, but they give relatively strong light at much lower currents. I have experimented with my cube and I have found that multiplexing (fast switching) does not influence this at all. In other words, designing the cube to work at 20 mA per LED might not be needed at all. I'm giving my LEDs 1.6 mA (1K + 82R resistors for each LED) and they are quite bright. Not as bright as at 20 mA, but still bright enough (I'm guessing about 70% as bright as at 20 mA). Full brightness may actually be an undesired thing, as the LEDs in the lower planes might shine through the ones that are above them. What I'm trying to say is that you can put 1K (or heavier) resistors to the LED cathodes instead of the originally intended 82 Ohm ones. This will reduce the current consumption of the cube considerably, you'll get away with a much weaker power source and maybe even the MOSFETS and shift registers could be replaced with ones that work at lower currents :slight_smile:

Here's the first video of the cube, running a test pattern :slight_smile:

Did you end up changing the hardware between replies 214 & 215?

No, not yet. I expect to do it sometime in the next 2-3 days. Don't worry, I'll let you know what I find.
The reason why you don't see the ghosting in this video is that I've fixed it in the software by adding a 100 microseconds delay between turning the previous layer off and turning the current layer on. The hardware solution appeals to me more, so I'll definitely try it.

Time for some fun! 8)

Although the multiplexing is quite obvious on camera, it is almost completely unnoticeable for the human eye.

I've finally managed to take some time to try adding some pull down resistors directly between the anodes and GND to see if the ghosting disappears. No such luck. I've also tried to add them between the cathodes and the 5V. Still no joy.

Something is not shutting down quickly enough. I wonder what. Remember that when a new anode plane is turned on, the LED that is at the intersection of the new anode plane and old cathode column, briefly turns on, just enough to be visible to the human eye as a dim light. This suggests that the cathodes are not turned off fast enough (not the anodes) and they interact with the newly turned on anode plane although they should not. The minimum delay added in the software which fixes this is 75 microseconds (0.075 milliseconds). From what I understood from the TPIC6B595 shift regiters' datasheet, that's a lot more than the typical 200 nanoseconds specified as "Fall time, drain output". But there's also some propagation time there (see the "Switching characteristics" section in this datasheet: http://www.ti.com/lit/ds/symlink/tpic6b595.pdf). Could it be that some propagation times add up to produce this 75 microseconds delay? That's still hard to believe because the propagation times (high-to-low + low-to-high) are specified around 150+90 = 240 nanoseconds. 75 microseconds divided to 240 nanoseconds is still about 300 and I doubt that I have 300 propagations (whatever that means) on 2 shift registers. Still, the cathodes are driven directly by the shift registers, so I can't imagine any other culprit... or could it be something to do with the capacitors that we use at the shift registers?