Hey guys so I'm working on a group project to create basically a 5x5x5 LED Cube. However we want to make this a little more unique and might need some help on the feasibility of it. The idea is that the cube takes advantage of a gyroscope to determine which way the cube is setup. If placed normally on a table (like a rubik's cube), the entire bottom layer is blue. When you rotate the cube, the LEDs "flow" like water. Now the problem that comes to mind is the wiring of the LEDs and the complexity of the programming. Would each LED have to be individually controlled? My thought is that if in parallel, it would be difficult to make the right LEDs fade or light up. Any help would be appreciated thanks!
Hey gammerx, most led cube projects use multiplexing to control the LED. No two Led's are ON at the same time. They are just being refreshed very quickly, and the eyes get fooled into believing that they are all on at the same time. Look into Persistence of Vision (POV) to learn more about this. The Gyro part of it is not to bad ones you get the multiplexing down. In-fact, for your project, I think you would be better off with an Accelerometer since all you need is the cubes orientation. Gyros are used for Angular Velocity.
Jay
Well I know how current works and how the lights really blink like ~120 times a second or what not. Thats why in high speed video you can see the blinks. Will have to look into the multiplexing part for the LEDs, and will use an accelerometer then if that is for orientation. The programming wouldn't be hard to have the LEDs light up with the accelerometer?
EDIT: SO I understand multiplexing for lets say a 5x5 grid, and that will require 10 pins/transistors. But how do I apply that to a 5x5x5 cube where those 10 pins can stack up veritcally?
Rather than a gyro, I think an accelerometer would be a better way to determine which way is up.
"most led cube projects use multiplexing to control the LED." True
"No two Led's are ON at the same time." False.
I believe many (most?) cubes multpiplex whole layers.
So a 5x5 might have 4 shift registers sinking current thru the cathodes of LEDs 1-25 on layer 1, with a P-channel MOSFET, or PNP, as he Anode driver providing the current for that layer.
Then the cathdes are updated, and the next Anode driver turned on.
Can have very fast refresh that way.
I was thinking of making a 9x9 cube with my 96-bit shift register driver board.
81 bits to sink cathodes,
9 bits to pull 9 P-channel gates low layer by layer.
Array with 12 bytes/layer to hold the layers info and the cathode info for that layer.
OE/ is wired up, so it'd be
void loop(){
if (time for array layer change){
OE/ off,
increase layer count, reset to 0 if reach 9 (layers 0-8)
shift out 12 bytes via SPI.transfer for:next loop
OE/on
}
update array for any pattern, etc
} // end loop
I'm waiting on deilvery for 10 of these boards if any one feels ambitious.
Can also use them to drive 12 common anode 7-segment displays. $6/PCB mailed to you.
'328 controlling 12 TPIC6B595 high current/high voltage open drain shift registers (current sink only).
Current limit resistors go off-board with the LEDs.
CrossRoads:
"most led cube projects use multiplexing to control the LED." True"No two Led's are ON at the same time." False.
I believe many (most?) cubes multpiplex whole layers.
So a 5x5 might have 4 shift registers sinking current thru the cathodes of LEDs 1-25 on layer 1, with a P-channel MOSFET, or PNP, as he Anode driver providing the current for that layer.
Then the cathdes are updated, and the next Anode driver turned on.Can have very fast refresh that way.
I was thinking of making a 9x9 cube with my 96-bit shift register driver board.
81 bits to sink cathodes,
9 bits to pull 9 P-channel gates low layer by layer.
Array with 12 bytes/layer to hold the layers info and the cathode info for that layer.
OE/ is wired up, so it'd bevoid loop(){
if (time for array layer change){
OE/ off,
increase layer count, reset to 0 if reach 9 (layers 0-8)
shift out 12 bytes via SPI.transfer for:next loop
OE/on
}
update array for any pattern, etc
} // end loop
So with that board, I could have 120 outputs? (from what the picture looks like.) I don't know if that would be a good idea to control all of them individually. In your method you are saying that on each layer, you link up all of the cathodes, and then link up rows of anodes? That could actually work for the idea of a water flow cube because if the cube is upright, the entire bottom layer is supposed to be lit up
There are 96 TCIP6B595 outputs. The last pin on the headers connects to Vin or to 5V, jumper selectable.
The TCIP6B595 are daisychained and supplied by SPI.
So one shifts out the cathode data for all xx cathodes and the anode for that layer. With 20mA LEDs (really bright!) you'd need 1.82A of current with 91 LEDs.
9 refresh cycles for 9 layers.
Or maybe do 1/2 of the layer, then the other half of the layer, and just need 1A of current. 18 refresh layers. Still have to shift all the data for the whole layer.
The remaining '328 IO pins are broken out near the '328, with a couple driving 2 transistors, or one can leave the transistors out and jumper across them.
The analog pins have +5, GND near them, the remaining digital pins have Gnd near them.
Wouldnt that cause problems on the corners? For example, place a rubiks cube on one of the points, so that no side is touching the surface. If the cube was a containers and water was in it, the water's shape would be an updside-down pyramid. Now we want to replicate that with LEDs. The lights cannot go all the way up the side, so we can't have an entire row/column lit up. Would that work?
Huh?
Lets make the math a little easier, say an 8x8x8 cube.
For each layer, you then have 8 bytes that represent the states of the LEDs in that layer.
Once a millisecond:
You turn off output enable, send out the 8 bytes for layerX, turn on the anodes for that layer
While waiting for the next millisecond, you update the layers data
So shifting out 9 bytes at 4 MHz will be pretty quick, do the math on it.
9 bytes, 8 bits/byte = 72 bits, something like 0.018mS?
So lots of time in between layer updates to do other stuff,
and whole still updated every 8mS.
Array refresh something like this:
// define these prior to void setup, put some data in if wanted
byte layer0[] = {B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000}; // 1 LED on in each byte
byte layer1[] = {B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000, B00000001}; //
:
:
layer7[] = {B10000000, B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000}; //
// these will not change and turn on the layers
anodes[] = {B00000001, B00000010, B00000100, B00001000, B00010000, B00100000, B01000000, B10000000}; // 1 anode on at a time
now put that in a loop as described above
[code]
// assumes that 8 layer shift registers and the anode shift register are daisy chained, with the OE pin controlled also
currentMillis = millis();
if ((currentMillis - previousMillis) >= interval){ // interval like 1 or 2 milliseconds
previousMillis = previousMillis + interval;
digitalWrite (OE, HIGH); // turn off all drives
layerCount = layerCount +1;
if (layerCount ==8){ layerCount = 0;} // reset to bottom layer
// there's a better way to do this, but:
switch (layerCount){
case 0:
digitalWrite (shiftRegSS, LOW);
for (int x = 0; x<8; x=x+1){
SPI.transfer(layer0[x]);
}
SPI.transfer (anodes[x]);
digitalWrite (shiftRegSS, HIGH);
digitalWrite(OE, LOW);
break;
:
:
case 7:
digitalWrite (shiftRegSS, LOW);
for (int x = 0; x<8; x=x+1){
SPI.transfer(layer7[x]);
}
SPI.transfer (anodes[x]);
digitalWrite (shiftRegSS, HIGH);
digitalWrite(OE, LOW);
break;
} // end switch
} // end time check
// do whatever you're gonna to update the layer arrays, like making all the bits that represent a face high
} // end loop
[/code]
Imagine a sealed plastic cube 1/5 filled with water. Imagine what happens when you rotate it in any way. We want to replicate this with LEDs. Turning on entire rows of LEDs at the sametime will not work, the LEDs need to have an appearance of the flowing of water within the cube. So the LEDs will always be at the lowest point of the cube depending on its orientation. There are no pre programmed animations, its flows with gravity so to speak. (an accelerometer will determine the orientation.)
Also, the center will be somewhat hollow, only the surface area will have LEDs so 6 sheets of 5x5s. Also, you are giving me information, but not sure what you are referencing.
I guess you want some like this
on the cube faces.
Ok, so 6 faces of LEDs, not a whole cube. No matter.
I only provided the means to display the data that represents the state of the LEDs.
You will have to develop the algorithm for deciding when that data changes, from 1 face being on, shifting to 4 faces being partially on in various amounts as the cube is tipped and/or rotated in various manners.
So Imagine you will also need some kind of 3-D angle sensor also to get that information from.
Lakes - Basically like that, I need to be able to control certain groups of LEDs at a given time, the accelerometer will determine which transistors to turn on and off as it is moved. However, I am not sure about the wiring of the transistors for the cube, that is mainly what I need help with. Doing one layer is easy, but how do I connect it to 6 different faces without using 100s of pins? Or should I just find a big enough board and in my case (5x5 6 times) that can use around 60 pins? Or could I even use additional transistors to reduce that amount?
Crossroads - yes, somehow the accelerometer will coordinate with which transistors we turn on, but I need help figuring out how this needs to be wired up
gammerx:
I need help figuring out how this needs to be wired up
As far as I understand it, the decision of which LEDs to turn on when is unrelated to the hardware. The conventional solution that Crossroads describes gives you a matrix of LEDs each of which can be turned on and off fast enough for them to appear to be on continuously. Isn't that all you need? It is then up to you to decide which ones you want on when to get the effect you're after, but that's purely a software issue.
PeterH:
gammerx:
I need help figuring out how this needs to be wired upAs far as I understand it, the decision of which LEDs to turn on when is unrelated to the hardware. The conventional solution that Crossroads describes gives you a matrix of LEDs each of which can be turned on and off fast enough for them to appear to be on continuously. Isn't that all you need? It is then up to you to decide which ones you want on when to get the effect you're after, but that's purely a software issue.
I need a method of being able to control each LED individually. This is achieved by multiplexing. What I need to know is how I can multiplex all 6 faces without having to use 60 pins.
Hello, gammerx. I hope this response is in time to help. I think what you need to look up is "Charlieplexing". That is how most of the LED cubes are done, and it is a way to control a lot of LED's with the minimal amount of pins. You can light one LED, All of them, Or any pattern.
Hope this helps.
Jay