The Charlie Cube Mark II: 4x4x4

Project Features

• Minimal hardware
• Wiring more complex than standard led cubes
• LED duty cycle 1/8

Update: There is a schematic and part list available here.
 
WARNING: Do not build this cube unless you know what you are doing! It uses minimal hardware but is difficult to understand.

There is a new design which is much easier to build with a very low part count.

Introduction

When I had finished my first charlieplexed LED cube (3x3x3) I wondered whether my next project should be a 4x4x4 cube. But at the time I thought it wasn't worth the effort. After all, I had just shown that a charlieplexed cube is possible and that it can be done with reasonable effort.

The 4x4x4 would of course have 64 LEDs, which would mean quite a lot of soldering. And since I would definitely want to use bright wide-angle LEDs, it wouldn't come cheap.

But the idea never really went away and when I found a good offer for a set of 100 suitable blue LEDs I simply couldn't resist.

Component selection

My 3x3x3 cube had been built with standard low cost 3mm LEDs, just because I had them already. The result was acceptable, but for this project I wanted to use bright LEDs with a wide angle beam so that the cube could be watched from various angles.

I found these interesting LEDs, which are no-name, but the data given is 150 mcd intensity at a viewing angle of 170 degrees. The viewing angle is achieved because the LEDs have a flat top instead of the normal lense shape. The LEDs produce blue light, but the LED body is water clear.

As for the controller, I couldn't use an 8-pin version, because I needed more ports. So I went for a 14-pin Atmel AVR ATtiny24, which was somewhere amongst my collection of left-overs. The tiny24 has only got 2kBytes of program memory, but there are pin and software compatible versions with more memory.

To get a brighter display, this time I went for a 1/8 duty cycle for the LEDs, so I had to activate up to 8 LEDs at a time. The controller I/O ports can't drive the necessary amount of current, so I used transistors as drivers, as in my very first post.

And that is about all the hardware I used.

For a conventional multiplexing scheme driving 64 LEDs, you would need 16 I/O ports (8 rows, 8 columns) and you would also need 8 drivers for your column ports. So apart from the number of ports, everything is the same.

In a conventional scheme you could trade ports for transistors by using a 16x4 matrix and therefor using only 4 drivers. But you then would need 20 I/O ports.

The charlieplexed variety of the cube only needs 9 I/O ports.

LED Matrix Structure

Similar to my post about charlieplexing, I would like to explain my systematic approach to the construction of the LED structure. It is important to use a regular structure, because it makes programming easier.

To start with, I did some math. I wanted to control 64 LEDs, so I needed 9 I/O lines: 8 x 9= 72.

A regular charlieplexed matrix looks like this - the LEDs are represented by blue dots. Bear in mind that column1 and row1 are controlled by the same port.

The matrix gets warped to remove the blank positions.

The last line of the matrix gets removed, because we only need 64 LEDs.

 

Now we trim this to a structure 4 LEDs high.

 

Finally we assign the 4x16 structure to units of 4x4. They correspond to the "slices" of the cube.

There are some useful properties in this structure. The two LED groups in each level are not connected. There are 8 groups (not 9), meaning we need only 8 transistors to drive them. All groups contain 8 LEDs in the same geometric pattern (2x4), so only one template is needed.

Building the Cube

There are loads of instructions on the net, how to build an LED cube. So I won't go into detail - only when it concerns the charlieplexed 4x4x4 version.

First I made 8 LED groups in a 2x4 configuration with common anodes.

The first two groups were soldered to a PCB.

 

On top came the next two groups. Notice the diagonal wires - just as in the structure diagram.

And another layer.

 Final layer - diagonal connections still open.

Now all columns are connected.

The same image, but with cathodes coloured.

Notice how the cube consists of two completely unconnected halves.

Each LED group needs its own anode connection, going directly down to the PCB (here before trimming for improved visibility).

The columns get connected.

The transistors (anode drivers) and the IC socket get added.

Done!

Schematics

Not much. There are the driving transistors. Since I wanted to make this a brighter cube than the first one, I decided to light the LEDs in each group simultaneously. So I needed transistors on the common anode. This is much like in my first post, but with more ports.

Other than that, there is just the controller, an ATtiny24.

Software Structure

On the lowest level, there is a hardware initialisation routine. It sets the I/O ports and then initialises CPU clock and a counter to trigger interrupt requests every millisecond.

There is an interrupt routine, which does nothing but transfer pre-calculated values to the port registers and implement a software timer.

The main routine sets the desired LED bits in an 8-byte array and then invokes a routine, which maps the bits of this array to port values.

To generate interesting patterns in an economic way, there are some pattern generation routines, like "set led", "clear all" or a "set column".

Finally, there are routines to generate a specific delay, in order to control the display timing of the patterns.

Possible Extensions

As mentioned earlier, I only had the ATtiny24 at hand. There are versions of this chip with more memory (ATtiny44, ATtiny84). Using one of them would make it possible to implement more patterns.

Sometimes you would like to create the same pattern in several directions (X,Y,Z). So it would be useful to be able to create the pattern and then rotate it to a different orientation. This can be done simply by swapping and negating coordinates. I implemented such an algorithm, but did not use it due to space constraints.

The controller has a few unused ports left. They could be used for other I/O, like a serial interface or for buttons. This way some kind of interactivity could be added.

The Source

If you like this project or just want to get some inspiration for your own project, download the source code here. It is written for AVR gcc under AVR Studio 4.

Update: There is a schematic available here.