Go Down

Topic: 8x8x8 multiplexed LED cube with an Arduino Mega 2560 (Read 41 times) previous topic - next topic


Can you add on to the 4x4x4 to expand it into the 8x8x8? If so, then you're already 25% done.
Designing & building electrical circuits for over 25 years. Check out the ATMega1284P based Bobuino and other '328P & '1284P creations & offerings at  www.crossroadsfencing.com/BobuinoRev17.
Arduino for Teens available at Amazon.com.


:) 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 :)


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:

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.


Feb 23, 2013, 12:03 am Last Edit: Feb 23, 2013, 12:07 am by Un4Seen Reason: 1
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:

Code: [Select]

   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:

Code: [Select]

   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...

Go Up