Building an 8x8x8 LED Cube – The Driving Circuit

LED Cube Driver Circuit - Complete Board - Front 04

In this article we are going to take a detailed look at how to build the driving circuit for the 8x8x8 LED cube. In other words we are going to design and analyze the circuit which translates the signals coming from the Arduino to appropriate currents passing through each of the LEDs, so that the desired animations can be created. We will go through the schematic, check the needed parts and we are going to see how to build the circuit exactly. If you haven’t read the introduction part yet, which talks about what we are trying to achieve in general, it’s probably a good idea to read it before we dive into the details of the driving circuit.

 

Power consumption

A very important thing to consider when designing a driving circuit for an LED cube is the maximum possible power consumption of the system, because the components and the power supply need to be chosen accordingly. The components that will drain most of the current are obviously the LEDs. Our cube is going to be one that is used with multiplexing (but we will do the multiplexing from the software, so we don’t need to worry about hardware multiplexing). This means that at any given time only one horizontal layer (plane) can be lit. In other words we need to plan for a maximum of N*N LEDs consuming power. In the 8x8x8 cube this means that we’ll have to take into account the power consumption of 64 LEDs, but if you are building a cube of a different size, you’ll need to adjust the calculations accordingly.

So how much current can an LED drain? Well, that depends on the value of the current limiting resistors that we use for each one of them. But the standard 3 mm (or 5 mm) LEDs of today are usually rated at 20 mA. We will design the circuit to be able to handle 20 mA of current per LED because there is a wide selection of LEDs out there and you might need to really give them 20 mA to shine brightly. However, I have found that most LEDs need much less current in order to shine brightly. For my own LED cube I have used standard 3 mm bright blue LEDs. For these the optimal brightness is obtained at 1.5 mA, which is obviously much less than their 20 mA rating. I’d like to emphasize here that figuring out the optimal brightness of you LEDs before you start building the cube’s driving circuit is very important. If your LEDs won’t be bright enough, the cube will look pale and that’s not something that we want. On the other hand, if the LEDs will be too bright, they will shine through the LED which is above them in the cube and it will seem that the above LED is also lit. This is even worse than a pale cube. So experiment with  your LEDs, in darkness and in daylight and determine how much current they need to shine with the exact brightness that is needed. Note that the value of the used current limiting resistors will also depend on the color of the LEDs because LEDs of different colors have different voltage drops. Here is a quick reference of the LED forward voltage values by color.

Getting back to the circuit design, we will plan for a maximum current of 20 mA per LED and a maximum of 64 LEDs being lit simultaneously. That means a total consumption of 1.28 A. That’s quite a lot and we’ll need a power supply rated at least at 1.5 A, preferably at 2 A. Should you decide to feed your LEDs with less current, a smaller power supply will suffice. In my circuit I have given them about 1.5 mA, so for 64 LEDs that’s a total of only 92 mA and yet the brightness is good enough. For 3 mm or 5 mm white or blue LEDs most likely the same current values can be used. For other colors you might need to give them a bit more current or even if the same amount of current will be enough, you’ll need resistors of different value.

Let’s also keep in mind that the LEDs are not the only components in the circuit which consume power. The other components (like MOSFETS and shift registers) also use up some current, but that is close to a negligible value. There is however something else. The multiplexed cube needs to switch between the layers very fast, in a matter of a few milliseconds or even less than one millisecond. Some of the components, like the MOSFETs which switch the layers, need time to shut off. I have found that some resistors are needed between the anode layers and the ground and the cathode columns and the positive voltage in order to help some currents go away after switching layers, otherwise they will go away through the LEDs and that will result in ghosting (when a layer is switched on, the previous layer is also dimly lit, which looks very bad). So, to get rid of this ghosting, I have added a 1K resistor between each anode layer and the ground and a 10K resistor between each cathode column and the positive voltage. In a 8x8x8 LED cube we have 8 anode layers and 64 cathode columns. Given the fact that the whole circuit functions at 5V, this means that the resistors between the anode layers and the ground will generate a total current consumption of 8*5 mA = 40 mA. The resistors between the cathode columns and the positive voltage will generate a total of 64*0.5 = 32 mA current consumption. That’s 72 mA overall. Unfortunately this is a passive power consumption, meaning that the cube will consume at least this this much, even if all the LEDs are off.

Finally, let’s not forget the power consumption of the Arduino which powers the cube. You will most likely want to power it from the same supply unit, so it too adds to the consumption. This will depend on the exact model that you use but even the most power hungry ones will not eat up more than 200 mA. Unfortunately it’s likely that we’ll need a model which uses quite some current (but not more than 200 mA) because the code that generates the animations will need a few kilobytes of memory, so a more powerful microcontroller (with enough memory) is needed for it.

 

Schematic

So, without further ado, allow me to present the schematic of the driving circuit. Please note that it was designed by Robert Patterson, also known as CrossRoads at the official Arduino forum. It’s he who we have to thank for this wonderful design. To check out more of his great circuits, visit his website at http://www.crossroadsfencing.com/BobuinoRev17/.

LED Cube Driver Circuit - Schematic

 

Serial communication between the Arduino and the shift registers

As explained earlier, in the introduction, we are going to use serial-in, parallel-out shift registers in our LED cube driving circuit, so that we can minimize the connections between the Arduino and the circuit. The data between the Arduino and the shift registers will be transferred via serial communication, through SPI. The Arduino will have the role of the master and the shift registers will be the slaves. The shift registers can be chained, meaning that the output of the first one can be fed into the second one, the output of the second one can be fed into the third one, and so on. This allows us to minimize the communication lines between the Arduino and the driving circuit because the Arduino only needs to send data to the first shift register in the chain and this first shift register will pass on the data, until it reaches the very last one. To understand how shift register work, check out this great video by Kevin Darrah:

In a circuit which drives an LED cube made of N*N*N LEDs, the number of shift registers needed is N+1 (this is true if N<=8). One is needed to switch on/off the anode planes and the rest of N shift registers are needed to switch the cathode columns. The TPIC6B595 shift registers that we use have 8 outputs, meaning that each shift register can drive up to 8 anode layers or 8 cathode columns. The first shift register in the chain is assigned to the anode layers because switching these is the most important and data from the Arduino reaches this shift register first. If you consult the datasheet of the TPIC6B595 shift register, you will see that the data is propagated from one shift register to the next very fast, in a matter of a few nanoseconds, so if the Arduino needs to send some data even to the last shift register in the chain, it can just push it through the whole chain quite fast, until it reaches the last one.

The most important thing to understand is that whenever the Arduino wants to change the state of any LED in the cube, it will actually update all the shift registers in the chain (with (N+1)*8 bits of data in total). It will first send the 8 bits of data which need to be in the last shift register and these first 8 bits will go into the first shift register first, but when it  will send the next 8 bits of data, the first shift register will make room for these next 8 bits by flushing out the first 8 bits, into the next shift register. The third transfer of 8 bits will push the data from the second shift register into the third one and from the first shift register into the second one. This way, after N+1 transfers of 8 bits, the first 8 bits will arrive into the last shift register in the chain, the second 8 bits will arrive into the one before the last and so on. The 8 bits which are sent out last will remain in the first shift register in the chain.  This means that the state of the cube changes all the time during the communication between the Arduino and the shift registers, but this happens so fast (in a few hundred milliseconds at most) that the human eye will not see any of it happening. Quite a nifty trick.

Unlike most LED cube driving circuits out there, which use the popular and ridiculously cheap 74HC595 shift register, ours has TPIC6B595 shift registers in it. This is because we plan for relatively high currents (if we really plan to give a maximum of 20 mA to the LEDs) and we need to sync the current, not source it, because of our anode layer and cathode column design. But the TPIC6B595 is also cheap enough and it switches fast enough (in a few nanoseconds).

As shown on the schematic, only 3 pins are needed for the serial communication between the Arduino and the first shift register: master out, slave in (MOSI), clock (SLCK) and slave select (SS). The MOSI pin of the Arduino is connected to the SER IN pin of the first shift register in the chain, than the SER OUT pin of the first shift register goes to the SER IN of the second one and so on. This is how the shift registers are chained (this is how data goes from one to the next). The SCK (SCLK) Arduino pin is connected to the SRCK pin of all shift registers. The SS Arduino pin is also connected to all the shift registers, to their RCK pin.


Switching the anode layers with MOSFETS

While only a maximum of 20 mA can travel through each cathode column (which means that the cathode column can be connected directly to an output pin of a TPI6B595 shift register), the situation of the anode layers is different. They can have up to N*N LEDs lit up at once, so in an 8*8*8 LED cube up to 1.28 A of current can go into an anode layer. This can obviously not be handled by the output of the shift register which controls the anode layers, so we need something that decouples these large currents from the anode layers’ shift register. The solution is to use NDP6020P MOSFETS. It’s important to note that not only can they handle the maximum possible current that goes through the anode layers, but also they switch on/off fast enough (in a matter of a few hundred nanoseconds in the worst case). This is crucial because of the multiplexing used in our cube (switching between layers very fast to trick the human eye and make it think that all the layers are on, while in reality only one is). The ability of the NDP6020P MOSFETS to switch very fast is explained by their low Rds(on) value (seen in their datasheet). This is what sets them apart from many similar components that exist.

Each output of the first shift register (which handles the anode layers) is connected to an NDP6020P MOSFET’s gate through a 220 Ohm resistor. The source pin of the MOSFETS is connected to the 5V power, from where it directs the current to the appropriate anode layer of the cube (through the drain pin) when the shift register switches it on. When the appropriate output pin of the TPIC6B595 is switched on, the output pin acts as low, switching the MOSFET on. When the shift register’s output pin is switched off, the MOSFET is pulled high through the pull-up resistor between its gate and the 5V positive voltage. For this pull-up resistor 5.6K or 3.3K values are fine.


Limiting the LED currents

The brightness of the LEDs in the cube is determined by how much current we allow to flow through them. This is determined by the current limiting resistors that are connected between the LED cathodes and the outputs of the N shift registers which drive the cathode columns. This means that for a cube consisting of N*N*N LEDs we are going to need N*N current limiting resistors of the same value. The value of these resistors depends on how much current we want to give the LEDs, as discussed earlier. The value of the current further depends on the type and color of the LEDs. However, we know that our circuit works with 5V, but the MOSFETS and the shift registers loose some of that voltage, so the value of the current limiting resistors should be calculated with approximately 4.89V (suing Ohm’s law or the LED resistor calculator).


Eliminating ghosting

Unfortunately the clean design of the driving circuit has to be complicated a bit by adding some resistors between the positive voltage and the cathode columns and between the ground and the anode layers respectively. Their role is to help dissipate some currents which would otherwise go through the LEDs when the LEDs are actually switched off. This would result in some ugly ghosting (some LEDs lighting up in a dim fashion when they are supposed to be completely off). The software also needs to be aware of this and wait for a few microseconds between switching one anode layer off and switching the next one on (think of multiplexing). During these few microseconds these unwanted currents are directed away through the resistors. Between the cathode columns and the positive voltage we will add 10K resistors. Between the anode layers and the ground we need to add 1K resistors.

I have struggled a lot until I have finally managed to figure out this solution for the ghosting issue that existed in my test cube. I wish to thank all the members of the official Arduino forum who have given me a hand with this and also to IQJar’s reader Robert Sukhudyan, who has pointed me in the direction of this article, which also deals with a similar solution to a ghosting problem (see the section entitled “Eliminating ghosting”).


Miscellaneous considerations

Let’s not forget to add small, 0.1 uF ceramic capacitors between the +5V inputs of the shift registers and the ground. Some other higher value (perhaps 10 uF) electrolytic capacitors in parallel are also welcome.

One other thing to keep in mind is to connect the GND of the driving circuit to the GND of the Arduino.


Driving circuit PCB

To make building the driving circuit easier, I have designed a printed circuit board to hold all the components. The board, which is 140*120 mm in size, has all the right connections and can safely be used to create the driver circuit for an LED cube of N*N*N, where N<=8. Of course, it’s possible to build the driving circuit on prototyping boards or with some other methods, but this printed circuit is a much cleaner and safer solution, with no ugly wires hanging around.

This is how the design looks from the front:

LED Cube Driver Circuit - Design - Front

and from the back:

LED Cube Driver Circuit - Design - Back

I have created my own driving circuit based on this design and it works perfectly, so we can consider the design to be tested. My real driving circuit board based on the above design turned out like this when viewed from the front:

LED Cube Driver Circuit - Bare Board (Printed Circuit) - Front

and it looks like this from the back:

LED Cube Driver Circuit - Bare Board (Printed Circuit) - Back

Finally, here are a few images of the finished driving circuit, with all components soldered in:

LED Cube Driver Circuit - Complete Board - Front 01

LED Cube Driver Circuit - Complete Board - Back 01

LED Cube Driver Circuit - Complete Board - Front 03

LED Cube Driver Circuit - Complete Board - Front 05

LED Cube Driver Circuit - Complete Board - Front 02

All the files necessary to manufacture the PCB for the LED cube driving circuit (PDFs, Gerber files, miling files, drill data) are available for download here.

So have fun building the driving circuit! The next article about building the 8x8x8 LED cube is going to explain how to build the cube itself, in detail.




Building an 8x8x8 LED Cube – Introduction

What is an LED cube?

An LED cube is exactly what the name suggests: LEDs arranged in the form of a cube. Why is that good? Because you can run very nice 3D animations on it! It basically acts as a very low resolution 3D display. I suppose I could go on forever trying to explain what an amazing thing an LED cube is or how it’s a piece of electronic art, but it’s better if you just watch this video and  see for yourself:

Are you amazed? Well, I certainly was when I had first discovered that LED cubes exist. They just looked so different from anything I had seen before. So… cool, so… futuristic… so… amazing! Naturally, I had decided that I just had to have one! But I did not know anything about them so I had gone through all the questions that somebody who does not know much about them would ask. In the following I’ll guide you through these questions (with answers, of course) and explain why if you want to have an LED cube, you have to build your own 🙂

 

Where can I get/buy one?

The short answer is: if you want a cube that is big enough to run really cool animations on it… you can’t really  get or buy one. If you can be satisfied with a small cube (say 4x4x4 LEDs or 5x5x5 LEDs), you can search the Internet and you will find a few for sale. The prices will be up to around 100$. But if you are like me and you want one that is bigger and can display nicer 3D animations (say an 8x8x8 cube), then you will most likely not find any for sale or if you will, it will cost a small fortune. There are several reasons for this:

  1. Building an LED cube takes a lot of work. The few people and companies who do make them, will have to charge enough money for them to cover their costs (most of which will be in the work, although for bigger cubes the components can cost quite much too) and make a profit. That translates to the buyer paying a lot of money for the end product.
  2. Building an LED cube and running 3D animations on it takes a lot of technical knowledge, both in the hardware and software area. Not many people and companies have all this knowledge (compared to how many we are on the face of the planet) and even fewer will actually make them to sell them, because it’s a lot of work and few people will be willing to pay a high enough price for the cubes to be worth producing and selling.
  3. LED cubes are a relatively new thing. They have been around for only a few years, so maybe the big companies have not yet recognized the potential in their mass production (if there is any).
  4. LED cubes are quite fragile. Transporting them can be very problematic.

 

OK, so… if I can’t buy one…

 

How can I build my own?

Now this is certainly the million dollar question. Unfortunately the answer is very complex. But I can tell you from start that you will need to invest an immense amount of work and that you will need a huge amount of patience to get it all done. You will also need much time and one or two hundred dollars for components. Is this all worth it? Well… that’s for everybody to decide for themselves. I’d say yes. If you see the awesomeness in the LED cube and if you like building your own things anyway, if you are willing to spend hundreds of hours of work on it (I’m not kidding, it’s a big project) and if you can invest a little money too, then you can start dreaming about having your own LED cube. Make a hobby out of it and build it!

This article and the ones to follow are meant to make the job easier for you. I will try to synthesize all the information that is in my head about building an LED cube and serve it to you in a manner which will save you work, time and headaches, so that your cube will be completed faster and look better when it’s done. This is a project that requires more than basic electronics hardware knowledge and skills and also software development knowledge. If you’re a total beginner in any of these areas, then you’re in for a hell of a ride. But if you’re motivated enough, eventually you’ll pull through. With the software part you can cheat: I will make my code available for download so you can just use that for start and try to customize it later if you wish. So don’t let the fact that it’s hard to build an LED cube demotivate you. Good things usually take a lot of work, but in the end you will have something… magic!

 

So how does this thing work?

What we see as 3D animations running on the LED cubes are basically fast changing 3D patterns/shapes displayed with LEDs. What it all comes down to in the end is lighting the appropriate LEDs at the right time. It’s all about controlling the LEDs. For that you need a microcontroller, like an Arduino, for example. You can think of the microcontroller as the brain of the system. It’s basically a very small and very simple computer which runs the software that tells it which LEDs to light up when. It transmits some signals to a driver circuit which translates these signals into electric current passing through the appropriate LEDs. So, in other words the software decides which LEDs need to light up at a given moment of time, the microcontroller transmits transmits these decisions to the driver circuit in the form of signals and the driver circuit lights the LEDs up.

 LED Cube - Main Components

Once you get the hang of it, working with a microcontroller, programming it, is not that hard, especially if you have an Arduino, which takes the easiness one step further. They are also relatively low cost. There are many cheap microcontrollers and a typical Arduino costs around 30-40$. you can also buy Arduino clones, which are usually just as good as the original ones but twice as cheap. For example I use a Tosduino Mega 2560 with my LED cube.

 

How are the LEDs controlled exactly?

As stated before, running the 3D animations is all about being able to control the LEDs individually, lighting them up at the right times, in the right combinations. An LED has two legs: an anode (positive leg) and a cathode (negative leg). If the right amount of electrical current passes from one leg, through the LED, to the other leg, it lights up. So  in order to be able to control each LED individually, you would need twice as many wires as LEDs (because they have two legs). But an 8x8x8 cube contains 512 LEDs, so that would mean running 1024 wires through the cube. That would certainly ruin the aspect of it and would also be next to impossible. And we did not see so many wires in the video. In fact we saw none. So how is it done?

The first trick is to use the legs of the LEDs to conduct electricity instead of wires. For example, if you solder the cathodes of all the LEDs which are above each other in the cube together (the cathode of the top LED to the cathode of the LED below it, that one’s cathode to the one which is one level lower and so on), then you only need to take a wire to the cathode of the lowest LED in the vertical column, the current will travel all the way up to the top LED through the cathode legs which are connected together. If the legs of the LEDs are not long enough to place the LEDs far enough from each other, you can use craft wire (beading wire) to fill the gaps, to take the current from one LED’s leg to the next LED’s leg. This is a strong metallic wire used by jewelry makers which has similar shine to the LED legs, so it will look nice. In most cases it is silver plated copper wire, which conducts electricity well, which makes it a good choice.

The second trick is to organize the LEDs into vertical columns and horizontal planes. All the columns will have the same polarity and all the planes will have the same polarity. For example we can form the vertical columns by soldering the cathodes together which are below each other and we can form the horizontal planes by soldering the anodes together which are next to each other. This way we will connect the anode planes to the positive voltage (+) and the cathodes to the ground (-) and the LEDs will light up. The images below show how to organize the LEDs into anode planes and cathode columns (the black columns are the cathodes connected together and the red planes are the anodes connected together).

LED Cube Anode Planes and Cathode Columns - Top View

LED Cube Anode Planes and Cathode Columns - Top View

LED Cube Anode Planes and Cathode Columns - Top View

LED Cube Anode Planes and Cathode Columns - Side View

LED Cube Anode Planes and Cathode Columns - Side View

Note that the cathode columns and anode planes never touch. That would be a short circuit, not something that we want! Instead, at the intersections of columns with planes we have the LEDs, which will light up when the planes are connected to the positive voltage and the columns are connected to the ground.

OK, OK… but we don’t want all the LEDs to light up together. We want them to light up individually. No problem! If we want to light up for example the LED in the second plane and in the fifth column, we connect the second plane to the positive voltage and the fifth column to the ground and leave the rest unconnected (this will be the job of the driving circuit – to switch the planes and columns on and off). Similarly, if we want to light up the LED in the third layer and in the sixth column, we’ll connect the third layer to the positive voltage and the sixth column to the ground. Or if we want all the LEDs in the fourth layer to light up, we’ll connect the fourth layer to the positive voltage and all the columns to the ground. The LEDs which have their anodes connected to the positive voltage and their cathodes connected to ground will all light up. Easy enough. And we only need as many wires as columns and layers. In an 8x8x8 LED cube we will have 8×8=64 columns and 8 layers (horizontal planes). So we will only need 64 wires connecting the columns to the ground (which can easily be concealed in a box below the cube) and 8 wires to the horizontal planes. If we’ll use craft/beading wire for the planes (to conduct the electricity between the planes and the circuitry in the box below the cube), which has the same shiny appearance as the LED legs, they will go unnoticed.

 

Multiplexing

Let’s try to imagine how we could light up, using the method described above, two LEDs at the same time, one that is situated in the second layer and in the fifth column and one that is in the third layer and in the sixth column. We will need to connect the second and third layer to the positive voltage and the fifth and sixth column to the ground, leaving all other layers and columns unconnected. This will light up the two desired LEDs which are at the intersection of the connected layers and columns, but unfortunately it will also light up two more LEDs: the one from the second layer and and sixth column and the one from the third layer and fifth column. This is because these other two LEDs are also located at the intersection of the connected planes and columns. So using less wires than theoretically possible bites back and more LEDs light up than desired.

To get around this problem we will use something called multiplexing. A multiplexed LED cube is one in which only one layer is turned on at any given time. The layers are turned on one after the other (for example from bottom to top) so fast (each one is on for only a few milliseconds) that the human eye sees the cube as if all the layers were on. The technique relies on something called POV (Persistence of Vision). Fortunately for us, LED cube makers, when the human eye sees an image, that image persists on the retina for approximately 1/25 seconds (about 40 milliseconds). So if we turn on the LED cube’s layers one after the other fast enough, it will seem that all layers are on. This solves the previously described problem because if only one layer is on at a time then all we have to do is connect that single layer to the positive voltage and connect the appropriate columns to ground (the cathodes of the LEDs which need to be on in the currently lit layer). As we switch from one layer to the next one, we also change the grounded cathodes and this way we can achieve any pattern we want. Following our previous example, if we want the LED in the second layer and fifth column (2, 5) and the LED in the third layer and sixth column (3, 6) to appear as on, then we will ground the fifth cathode column when the second layer is on (connected to positive voltage) and we will ground the sixth cathode  column when the third layer is on. The problem of the two other LEDs ((2, 6) and (3, 5)) lighting up is gone!

Another major advantage of multiplexing is that because at any given time only one layer is on, the maximum power consumption of the cube drops to as much as one layer can consume. So for an 8x8x8 LED cube, you’ll have to plan for a maximum current consumption equivalent to that of 64 LEDs instead o 512. This will allow the use of a power supply unit with much smaller rating (and price!) and generally less special, easier to acquire, cheaper components in the driving circuit.

You might wonder how we are going to switch the layers on and off fast enough. That’s a task for the microcontroller/Arduino. They are up for the job. An Arduino typically runs at 16 MHz (executes 16 million operations per second), so switching layers 25 times a second is really no problem. We will, however, want to switch layers even faster. 25 frames per second is just about the limit where the human eye starts to see flickering instead of LEDs being continuously on. But your brain might still be unconsciously suspicious even at faster rates. The faster we switch, the nicer and smoother the cube animations will look and even the brain will be convinced. I have found that keeping each layer on for one millisecond (1/1000 sec) leads to perfectly smooth shapes and animation. Even this is not a problem for he microcontroller/Arduino.

 

How many wires?

We have seen that, by organizing the LEDs into horizontal planes and vertical columns, we only need as many wires between the cube and the driving circuit as many layers and columns we have. So, for an 8x8x8 cube, we will need 8+64=72 wires between the LED cube and the driving circuit. We will also need just as many connections between the driving circuit and the microcontroller/Arduino if the driving circuit just “translates” signals of the controller to LED currents, the controller needs to be able to drive each column and layer independently. While having so many wires between the cube and the driving circuit is not a problem, having equally as many connections between the driving circuit and the microcontroller is impossible. Most microcontrollers (including the usual Arduinos) only have 10-20 pins that we can use to transmit signals to the driving circuit. Even the toughest, most badass Arduinos (like the Mega 2560) only have 54 available pins, which is still not enough…


Shift registers

Don’t worry, for every problem there is a solution. For this one in particular the solution is brought by shift registers (8-bit, serial-in, parallel-out shift registers, to be more specific). These shift registers are integrated circuits which can accept data in serial mode (data is fed to it one piece at a time, one piece after the other) and pass it on in parallel mode (all the data at once along several output pins). We will use them in our driver circuit to collect and store several signals from the Arduino and send them to the LED cube all at once. We will use 8-bit shift registers, which means that each of them will be able to store 8 signals received from the Arduino and send them to 8 LEDs of the cube, all at once. So, for 64 columns and 8 layers we will need 72/8=9 shift registers. The signals will be sent by the Arduino to the shift registers so fast (typically at 4 MHz, in other words at 1/4.000.000 sec) that even though it’s serial communication, from a human point of view it will appear to be instantaneous and all at once.

The communication between the Arduino and a shift register can be achieved with a minimum of 3 wires (3 pin connections). So that would suggest that for 9 shift registers we need 9*3=27 output pins from the Arduino. But things get even better! The shift registers can be chained together, meaning that you can send data from the Arduino to the first shift register in the chain and when the first shift register is filled up with 8 bits of data, it will shift out the data on its output pins right into the next shift register in the chain. When the second one gets full, it will shift out the data to he third one and so on. So, if we chain all the shift registers together, we will be able to control the whole cube with only 3 pins from the Arduino, regardless of how many LEDs there are in the cube, 512 or even more for bigger cubes. That’s just awesomeness in its purest form!

If you wish to understand in detail what shift registers are and how they work exactly, there is a most excellent video put together by Kevin Darrah which shows the workings  in “slow motion”. The Arduino will do the same, only extremely fast. So watch this video, it’s well worth a few minutes of your time (thanks Kevin!):

Worrying about costs? Don’t! 8-bit serial-in, parallel-out shift registers are relatively cheap, you can buy them for a few bucks a piece, so i’t’s not a problem that for the 8x8x8 cube we need 9 pieces.

 

What are we going to build exactly and how?

In the following articles I’m going to walk you through the steps of building an 8x8x8 single color LED cube. We will cover both the hardware and software side of the process, focusing on the hardest parts. The things that we will discuss are applicable to smaller cubes too (2<=N<=8, where N is the size of the cube) and, with a few exceptions, even to larger cubes (N>8).

Our cube will be driven by an Arduino and we will write the code that runs on it in the C++ language, uploading it onto the Arduino on a USB port, using the Arduino development software. I will provide the code that takes care of the multiplexing and an animation framework, which can be modified and extended arbitrarily.

The frame of our cube will be built using craft wire (beading wire). Although the frame will not be as straight and good looking as if we soldered the legs of the LEDs together directly, I prefer this method because it lets you space the LEDs further apart. In an LED cube visibility into the depth of the cube is very important and the distance of the LEDs influences that very much. Unfortunately, using additional wire to build the frame does mean more work and somewhat higher costs.

We will build an LED cube in which the layers will be formed by the LED anodes and the columns will be formed by the LED cathodes. Usually people do it the other way around, but with our components this is the approach to take. We are going to use N+1 TPIC6B595 shift registers in our driving circuit to switch the N*N cathodes and the N anode layers after collecting several signals from the Arduino, and NDP6020P MOSFETS to switch the anode layers, allowing up to 20 mA of current per LED. The communication between the Arduino and the driving circuit will be achieved through SPI, using only 3 connection pins (MOSI, SCK and SS).

 

Some advice

  • Use 3 mm LEDs in your cube. Unless you place the LEDs very far apart (which makes the building process harder and the storage of the cube more problematic), 5 mm LEDs will make the cube seem crowded.
  • Use diffused LEDs instead of clear ones. Yes, clear LEDs look nicer when they are not on, but most of their light goes out through the top of the casing. This doesn’t only mean that the cube will not be as bright when viewed from the side (and an LED cube is almost always viewed from the side), but also that the LEDs in lower layers will whine through the ones above them, which will seem like the higher LEDs are lit when they actually are not. This is definitely not a desired effect!
  • Place the 3 mm LEDs approximately 3 cm apart to obtain a cube with enough space in it to easily see the LEDs in the back too.
  • Use some kind of helper jig (perhaps a piece of wood) to hold the LEDs in place while you solder them. You will also need small crocodile clips and/or some hair clips to keeps the LED legs and the craft wire together while being soldered.
  • If your soldering skills are weak, spend some time learning how to solder well before starting the cube. It is very important to avoid cold joints in the LED cube. After putting the layers together, the LEDs in the middle will not be accessible, so if a  joint breaks, it will be a huge problem. Good soldering avoids this. I recommend to apply some liquid flux onto the joints before soldering, and to always use solder which has flux inside its core. Here’s a useful video showing how to solder correctly:

  • Don’t try to build a big (8x8x8) cube as your first attempt to build an LED cube. Start with a small one (a 4x4x4 for example). There are many things during the build process which you need to try on a test cube before going for the big one. No amount of theory can prepare you for all the difficulties encountered during the build process, you need to experiment and see for yourself. You need to start with a small cube, which will not turn out perfectly. Check out this video of my 4x4x4 test cube. You can see that it’s not perfect, but it turned out alright:

  • Although standard LEDs are usually rated at 20 mA, design your cube for much less current. For super bright standard white and blue LEDs 1.5 – 2 mA is quite enough. For orange, red, green and yellow ones the same value (or a bit more) should be good, but you’ll need smaller resistors as these colors have smaller voltage drops. See this table for the voltage drop of standard LEDs by color. Running the LEDs at full brightness (20 mA) will be a bit bothering for the viewers’ eyes and it will produce the unwanted effect of lower LEDs shining through the ones above them. Lower LED currents will also mean a more power-efficient cube, which can be connected to a lower rated power supply unit.
  • The most important things that you need to build an LED cube are patience and perseverance!

 

So stay tuned for the detailed articles about:

    • how to build the cube
    • how to put together the driving circuit
    • how to write software for it

 

Sending emails from the Raspberry Pi

Email from the Raspberry Pi
There are many cases when it can be very useful to be able to send emails from the Raspberry Pi to arbitrary recipients. This is not the same as having a real MTA running on the Pi (like Sendmail, Postfix, Exim, QMail, etc.), which can also receive and store emails. In the following we are only going to cover the possibility of sending emails, not receiving. In most cases this is enough, as people tend to use GMail, Yahoo! Mail and other major email service providers and they store their emails on the servers of these providers. Still, sending out emails from the Raspberry Pi can come in handy in many situations. For example, you could have some sensors connected to the GPIO pins of the Pi and you could program the Pi to send you an email when the temperature in the room rises above or drops below certain threshold values, when a gas sensor registers unwanted gas leaks or when the measured voltage of a monitored battery becomes too low. You could also have your Pi send you daily or weekly emails with summarized system data. Or maybe you could connect a webcam to the Raspberry Pi and set up some motion detection software, which would send you an email as soon as it detects motion in a given area of your house. Maybe we don’t even need to go this far. Maybe you are hosting a WordPress website on your Raspberry Pi and you would like to provide your readers with the possibility to subscribe to the posts. This all means that the Pi needs to be able to send out emails, which, unfortunately, can be complicated to accomplish.
In order to achieve this we are going to install a piece of software called SSMTP, which is a simple tool for sending emails. We are also going to configure PHP in a way which is going to make it possible to send emails from inside PHP scripts. This way it’s going to be easy for web applications (like WordPress plugins) to send mails to chosen recipients.
Many email servers today have very strict rules for accepting emails. For example if the email is not coming from a machine with a static IP address, they might classify the email as SPAM. We don’t want that to happen with the emails sent from the Raspberry Pi, so we are going to send the emails to a Goggle server, which will send them forward to the real recipients. In order to be able to accomplish this, you must have a GMail account.

Installing and configuring SSMTP

1. Make sure your repositories are up-to-date:

apt-get update

2. Install SSMTP and mail utilitites:

apt-get install ssmtp

apt-get install mailutils

3. Edit the SSMTP configuration file:

nano /etc/ssmtp/ssmtp.conf

a) Mandatory lines:

root=postmaster
mailhub=smtp.gmail.com:587
hostname=raspberrypi
AuthUser=YourGMailUserName@gmail.com
AuthPass=YourGMailPassword
UseSTARTTLS=YES

Be sure to specify the correct GMail user name and password here, otherwise you will get authentication errors.

If the host name of your Raspberry Pi is different from “raspberrypi”, specify your actual host name here instead.

b) Optional lines:

rewriteDomain=your.domain

Specify this if you would like the outgoing emails to appear to be sent from your.domain (instead of from gmail.com).

FromLineOverride=YES

Specify this if you would like SSMTP to leave the From field of the emails untouched. Otherwise it will overwrite the from field with the name of the Linux user which sends the email. The overwriting name is taken from the 5th value in the line that corresponds to the sending user, from the /etc/passwd file. If you plan to send emails from a website (for example from a WordPress plugin) and wish to have nice sender names like “John Doe”, I recommend commenting this line (which is equal to setting the value to NO), otherwise your website will only be able to send emails with less nice sender names, like johndoe@your.domain. In other words, you probably want SSMTP to overwrite the sender field with a nice name taken from the /etc/passwd file.

4. Edit the SSMTP aliases file:

nano /etc/ssmtp/revaliases

This file contains data about the email accounts for existing Linux users in the format local_account:outgoing_address:mailhub[:port]

You should create one line for all the users in your system from which you plan to be able to send emails. For example:

root:root@your.domain:smtp.gmail.com:587
www-data:yourwebpagesname@your.domain:smtp.gmail.com:587

In case you wish to send out emails from a WordPress plugin, you must make sure that you have a line for the user www-data, which is the user under which WordPress runs.

5. Set the permissions of the SSMTP configuration file:

chmod 774 /etc/ssmtp/ssmtp.conf

The  permissions of the file /etc/ssmtp/ssmtp.conf determine  who will be able to send emails from the Raspberry Pi. By default this file is owned by the user root and the group of the file is also root. So if you want other users, like www-data to be able to send emails (which you definitely want if you’re using a WordPress plugin for example to send out emails), then you need to give read rights to the users who are not the owner of the file and not in the group of the file. The above permissions (774) mean that the owner (root) will be able to read/write/execute the file (7), the other users in the root group will be able to do the same (7) and the users which are not in the group will only have the right to read the file (4). For more details type chmod –help.

If you prefer not to allow every user on your system to send emails, then add the www-data user (or the user who you would like to grant permission for sending emails) to the root group and only give the rights to the users in this group:

sudo usermod -a -G root www-data
chmod 770 /etc/ssmtp/ssmtp.conf

Be careful though. Adding the www-data user to the root group might sometimes not be very safe, as it will allow your website to do many things on your system.

6. Nice sender names:

If you would like your website (WordPress for example) to be able to send emails which appear to be sent from a person with a nice name like “John Doe” or “Your super web site” instead of from a simple  sender name like you@your.domain, then you need to make sure that in the /etc/ssmtp/ssmtp.conf file the FromLineOverride line is commented (#) or set to NO and you need to give a nice name to the www-data user. You can do this by editing the passwords file:
nano /etc/passwd

Find the line corresponding to www-data and set the fifth value in it to a nice name like “Your super website”.

Sending emails from command line

Once you’re done with the above setup and configuration process, you can send emails very easily from command line, which is great because you can also put the sending into Bash scripts, which can be called by other applications running on your Pi. A simple example looks like this:

echo “Test text” | mail -s “Test Mail” targetperson@example.com

The text “Test text” is sent to the email address targetperson@example.com (you may also specify multiple addresses separated by spaces) with the subject “Test Mail”. For more options type mail –help.

Sending emails from PHP scripts

If you would also like to be able to send out emails from PHP scrips (which is the case if you plan to send emails from your website, perhaps from a WordPress plugin like Subscribe2), then you need to configure PHP to find the mail sending application.

1. Edit your PHP configuration file:

nano etc/php5/apache2/php.ini

Find (F6) the line which contains sendmail_path and set it to the appropriate value:

sendmail_path = /usr/sbin/sendmail -t -i

2. To test if PHP is indeed able to send out emails, create a file named mailtest.php and put the following code into it:

<?php
$to = “targetperson@example.com”;
$subject = “PHP Test mail”;
$message = “This is a test email”;
$from = “you@your.domain”;
$headers = “From:” . $from;
mail($to,$subject,$message,$headers);
echo “Mail Sent.”;
?>

Test by calling your script from command line:

PHP mailtest.php


Troubleshooting

If you fail to configure things properly, you might run into some errors when trying to send emails. Some common error messages are the following:

1. Authentication failure:

Authorization failed (535 5.7.1 http://support.google.com/mail/bin/answ … swer=14257 a1sm11494547eep.2 – gsmtp

The most probable cause of this is that you have specified a wrong username or password for your GMail account in the /etc/ssmtp/ssmtp.conf file. Double check the values of the AuthUser and AuthPass fields.

2. Connection lost in the middle of processing:

send-mail: Connection lost in middle of processing

Chances are you specified the wrong port for the Google smtp somewhere in /etc/ssmtp/ssmtp.conf or in /etc/ssmtp/revaliases.

3. Your website (for example your WordPress plugin) gives an error message when you try to send an email from it or it appears to have sent the email but it never arrives to the recipient(s):

Check the last lines of your logs. There should be some relevant error messages in there:

tail /var/log/mail.log

tail /var/log/syslog

One of the most common problems is that you have not given the www-data user rights to read the /etc/ssmtp/ssmtp.conf file. Check the permissions of the file:

ls -l /etc/ssmtp/ssmtp.conf

and if something is not right, set the permissions, for example:

chmod 774 /etc/ssmtp/ssmtp.conf


Live webcam feed from your Raspberry Pi

Webcam on RaspberryPi

If you have a Raspberry Pi and a compatible USB webcam, you can easily create a live online feed over HTTP. In other words, you can use your cam connected to your Pi to stream a live feed of anything you want over the Internet. You can use it for surveillance of your house or yard, to see what your dog is doing while you’re away, to watch the birds in a birdhouse or who knows what else you might come up with.

The software that we are going to use to transmit the video stream is called MJPG-streamer. It was written by Tom Stoeveken and is available at sourceforge.net:

MJPG-streamer acts as a small HTTP server installed on the Raspberry Pi, transmitting the video feed captured using the webcam over HTTP, in motion jpeg format. To view the feed, you can just open a web browser and type the address (IP or domain name) of your Raspberry Pi and the port number associated with MJPG-streamer. What’s really great about MJPG-streamer is that you can easily embed the feed into any webpage by using a simple IMG tag, as we will see a bit later.


Installation, configuration, testing

1. Connect the webcam to the Raspberry Pi via USB.

A list of compatible webcams can be found here, so if you plan to buy a new one, verify that it’s on the list. If you have one laying around, give it a try even if it’s not listed as compatible. I’ve personally tried 3 webcams, none of them being on the list and all of them have worked.

To verify that your webcam is recognized by the Pi, just plug it in and check that the /dev/video0 entry is present in the system:

ls dev/video0

2. Make sure your system is up to date:

apt-get update

apt-get upgrade

3. Install the libv41-0 package on the Pi:

apt-get install libv41-0

4. Download the mjpg-streamer package onto the Raspberry Pi. I have put together a custom package which should work well on the Pi (Please note that MJPG-streamer is the work of Tom Stoeveken and the start-up script originates from HowToEmbed.com, I have merely customized and enhanced the package in order to optimize it for the Raspberry Pi and to make it easy to use for our purposes):

wget http://iqjar.com/download/jar/soft/mjpg-streamer.tar.gz

5. Unpack the package:

tar -zxvf mjpg-streamer-rpi.tar.gz

6. Change into the newly created mjpg-streamer directory:

cd mjpg-streamer

7. Start the server application:

./mjpg-streamer.sh start

8. Test the live feed:

Open a web browser and in the address bar type the address of your Raspberry Pi and the port number associated with the mjpg-streamer server:

http://example.com:8083/?action=stream

(mjpg-streamer will start on port 8083 by default)


You should now see a live feed from your webcam in a web browser. If you want to embed this feed into a web page, just put this into the HTML code:

<img src=”http://example.com:8083/?action=stream” width=”640″ height=”480″/>

Simple and nice! Obviously you can change the width and height parameters, but you should make sure that they are not more than the actual resolution of the feed.

When you start mjpg-streamer, it is possible to tell it which port to listen to, what resolution and what frame rate to use. The syntax of the start-up script looks like this:

mjpg-streamer.sh [start|stop|restart|status] [port number] [resolution] [framerate]

That’s pretty much it! Start the feed, open it in a browser, sit back and enjoy!