Since I have not really touched more advanced electronics and embedded development before, I thought to myself I would start off with something a bit simpler and more software oriented, where I have my strengths. Then, after a bit of searching for inspiration, LED cubes caught my eyes, which are basically low-resolution (compared to everyday 2D/matrix displays) 3D/volumetric displays of LED's made of X rows (width), Y columns/pillars (height) and Z layers (depth), usually where X=Y=Z - resulting in a total of X³=Y³=Z³ LED's - and the shape therefore resembles a cube.
One of the larger examples of such is the AllSparkCube (Transformers, anyone?), a cube consisting of 16³ (4096) 10mm RGB common anode LED's (4 pins in total; 1 pin for the anode and 3 for the R, G and B cathode). This was economically sponsored by a company and made by a couple of guys in their vacation, using 16 custom designed circuit boards with some sort of DIP-16 shift registers (guessing 74HC595), an Arduino Mega 2560 and multiple forms of communication, including RS232 and WiFi. Each board is responsible for multiplexing 16² (256) LED's (1/16 matrix/panel/slice of the cube) and keeps up to 4 LED's (64 in total) illuminated at all times.
LED cubes are made in many variants, the most popular ones seems being 3³, 4³, 8³ and 10³ in both monochrome and RGB. Monochrome lighting is far cheaper (cheaper LED's and only needs about half as much multiplexing hardware) and a bit easier to construct (2 pins per LED instead of 4 also means about half as much wiring/soldering) but, of course, excludes all those pretty RGB colors. One thing, though, is that I fail to see why you want an even number of LED's per side if you intend to make slides/presentations with centered particles. It is much easier to make these if you have a true (single row) center line through all three axes, and therefore a true center point, which, naturally, requires an odd number of layers, rows and columns, like 3³, 5³, 7³, 9³, etc. I do, however, see the advantage of using an even number and fully utilizing the hardware, which usually consists of 2^n inputs/outputs per chip.
Another variable to consider is the sheer amount of additional LED's to connect from enlarging the size of all three axes of the cube. Depicted on the table below is this formula in numbers, where n is the length of either side in number of LED's, n² is the number of LED's per panel/matrix, and n³ is the number of LED's for an entire cube.
Size vs. Volume
|
Difference in Volumetric Size (x³-y³)
| ||||||||||
n
|
n²
|
n³
|
x/y
|
3
|
4
|
5
|
6
|
7
|
8
|
9
| |
3
|
9
|
27
|
3
|
-
|
-
|
-
|
-
|
-
|
-
|
-
| |
4
|
16
|
64
|
4
|
37
|
-
|
-
|
-
|
-
|
-
|
-
| |
5
|
25
|
125
|
5
|
98
|
61
|
-
|
-
|
-
|
-
|
-
| |
6
|
36
|
216
|
6
|
189
|
152
|
91
|
-
|
-
|
-
|
-
| |
7
|
49
|
343
|
7
|
316
|
279
|
218
|
127
|
-
|
-
|
-
| |
8
|
64
|
512
|
8
|
485
|
448
|
387
|
296
|
169
|
-
|
-
| |
9
|
81
|
729
|
9
|
702
|
665
|
604
|
513
|
386
|
217
|
-
| |
10
|
100
|
1000
|
10
|
973
|
936
|
875
|
784
|
657
|
488
|
271
| |
Referring to the AllSparkCube again, apparently they use shift registers and on-board resistors to limit the current running through each LED's to its optimal forward current, called If, usually around 20-30mA for 3mm/5mm LED's (note that an RGB LED would then use 20-30mA per R/G/B channel and therefore 60-90mA in total). Another way to limit the current is using constant-current sinks or sources, depending on whether the chips are sinking (cathode) or sourcing (anode) current. The other end of the LED is then controlled by some sort of simple PNP (anode) or NPN (cathode) transistor. For instance, a popular method of driving LED's (with common anode, in case it is RGB) is to use a TLC5940 for the cathode(s) and a PNP transistor, such as BC327 or TIP42C, for the anode. If you happen to use a microcontroller with lower output voltage than an LED (and therefore the PNP transistor) requires, you can always put an NPN transistor in between to drive the PNP transistor, since pulling to (the controller's) 0V is always possible. Also, NPN transistors come in Darlington-pair arrays, such as the ULN2803A.
For construction of the cube, most people choose to assemble it in horizontal layers (like stories in a building), one horizontal layer at a time, and then solder them together vertically later on. The problem with this method is that it is hard to solder the layers together in the middle, the larger the cube gets. Aligning the layers with each other vertically also presents a potential problem, though this is only another, easier task to solve. Finally, when you do get the cube running and if one of the LED's is damaged/broken (worst case is, naturally, one of those lowest in the middle), you have to disassemble almost the entire cube to replace it.
Another method, which is mostly overlooked, at least online, is to assemble the cube in vertical layers and solder them together horizontally afterwards. This method actually solves most of the issues of the first method, although it does introduce an issue of its own for the basic construction of each layer. It is more challenging to align each LED with others in its own layer with this method, whilst the first method is always accurate because you would normally just drill some holes in a piece of wood to hold the LED's in place whilst soldering.
The only place I have found the latter method described so far is on this site: HNTE - RGB LED Cube. The author, Nick Schulze, made clear illustrations and comparisons of these two methods, so I will just provide the most descriptive image here and leave all rights to him.
Well, I rarely focus my interest on some topic without a bit of deeper researching to expand my knowledge and explore some or all of my options. Therefore I could not just settle to use Arduino as my primary platform of development, but this is probably a discussion for another day. I first constructed a 3³ (27 diodes) cube before I started working on a larger 9³ (729 diodes) cube, which I am currently still working on. I am also still working on the software for both of them, so stay tuned for more blogging about these (and hopefully a future quadcopter)!
For construction of the cube, most people choose to assemble it in horizontal layers (like stories in a building), one horizontal layer at a time, and then solder them together vertically later on. The problem with this method is that it is hard to solder the layers together in the middle, the larger the cube gets. Aligning the layers with each other vertically also presents a potential problem, though this is only another, easier task to solve. Finally, when you do get the cube running and if one of the LED's is damaged/broken (worst case is, naturally, one of those lowest in the middle), you have to disassemble almost the entire cube to replace it.
Another method, which is mostly overlooked, at least online, is to assemble the cube in vertical layers and solder them together horizontally afterwards. This method actually solves most of the issues of the first method, although it does introduce an issue of its own for the basic construction of each layer. It is more challenging to align each LED with others in its own layer with this method, whilst the first method is always accurate because you would normally just drill some holes in a piece of wood to hold the LED's in place whilst soldering.
The only place I have found the latter method described so far is on this site: HNTE - RGB LED Cube. The author, Nick Schulze, made clear illustrations and comparisons of these two methods, so I will just provide the most descriptive image here and leave all rights to him.
Well, I rarely focus my interest on some topic without a bit of deeper researching to expand my knowledge and explore some or all of my options. Therefore I could not just settle to use Arduino as my primary platform of development, but this is probably a discussion for another day. I first constructed a 3³ (27 diodes) cube before I started working on a larger 9³ (729 diodes) cube, which I am currently still working on. I am also still working on the software for both of them, so stay tuned for more blogging about these (and hopefully a future quadcopter)!
