WonderTiger:
I did a measurement with a cheap digital volt meter and it came around 2.5V. I think I should invest in a better multimeter in the first place (a buddy of mine has an industrial fluke that works really well he said, maybe I should look for something like that) to get some accurate readings
There are many reasons one might want to upgrade to say a fluke DMM (I own 3) but for the kind of stuff your doing with a typical arduino project a simple cheap DMM (unless defective) will not be a big deal as far as accuracy goes. Like any tool, it's not so much the tool but rather knowing how to use it properly and understanding it's limitations. The biggest draw back of modern DMM is that it always displays a number even when the number being displayed doesn't mean what you might expect it to or want it to mean. Measuring the output of a active PWM pin is one example of a improper measurement for a DMM, it will display a number but it doesn't mean what you think it means.
I absolutely agree with the statement you made. However I think a good meter will be a good investment though (for my study and other projects in the future) even if it isnt really meaningful for now yet.
WonderTiger:
You're absolutely right with the statement you made. However I think a good meter will be a good investment though(for my study and other projects in the near future) even if it isnt really meaningful for these kinds of projects yet.
I agree mostly about good test equipment being a near lifetime investment that will pay good dividends for a long long time. After working for decades in the electronics industry I found that fluke meters and tektronix scopes were all I ever wanted to own for personal use.
But the point is that arduino beginners should be encouraged that their first purchase to make after their arduino board is a DMM, well before obtaining any other components and/or modules for their various projects. So the $10 DMMs serve a good purpose in at least getting them started on the right path. Many young people starting out just can't yet afford the investment costs of say a Fluke meter, but can swing for a $10 DMM which is much better then no DMM at all which all too many appear to have.
Been a while I posted something here. Last weeks I was very busy with school (we are developing a weighing scale). However I managed to make a very easy animation for my cube :), enjoy:
I've recently built a similar 4x4x4 cube. I'm having some trouble with ghosting on the cube (it seems that the cathodes are not turning off quickly enough). The way it manifests is that when I turn on a pair of a new anode plane and a new cathode column, the LED which at the intersection of the new plane and the old column, lights up for a brief moment. This results in ghosting. It is most likely a hardware problem, but I want to make sure that it's not a software problem. Have you had any kind of similar ghosting problem? Would it be possible for me to see your code, maybe I'll get some insights about what I might be doing wrong...
I have not seen 'ghosting'on my cube. However if I light up 1 layer, the layer above the lit one will shine very dim. But this is due the light goes through the bottom of the LEDs.
Yes, I have the shine-through effect too, but that's not a big problem and there's not much you can do about it anyway. Thank you for the code! I will check it.
I have noticed that you use shiftOut() instead of the SPI library that I use. Theoretically the SPI library's methods are faster, but I'll try out shiftOut() too, who knows, maybe it makes a difference...
Edit: Still the code I'm using is not a good way to program the cube. After a while u will run out of memory and the cube is going to do strange things. Even now I'm using PROGMEM its not working. Is it possible that you can post your code as well??
I have built a few cubes, and I dont think that I have noticed any ghosting. Do you have any videos of the ghosting?
My first cube only lit on LED at a time, I modified it to use shift registers and it lights 16 LEDs at a time. I havnt noticed any ghosting, but maybe its happening, and I just didnt notice?
@Hippynerd: If your cube would have ghosting like mine, you would notice it, trust me It is very visible and... annoying. Unfortunately I can't create a video as my camera is broken and even for my last video I had to borrow one (I really should get one...), but I can describe it the following way: when multiplexing is used, the ghosting is seen as the previously multiplexed (lit) layer turning off too slowly, so basically you see a ghost image (dim image) of the current layer in the previously lit layer. So, if you light up an LED in the bottom layer, you'll see the LED which is in the same column and in the top layer (bottom layer is lit after the top layer because the layers come after each other from bottom to top) dimly lit. If you light an LED in the second layer, you'll see the LED below it dimly lit. For the third layer the ghost will be in the second layer and so on.
@WonderTiger: Sure, you can check out my code here: http://iqjar.com/download/jar/LED_Cube/4x4x4/LEDQB_v0.4.ZIP
I've taken a slightly different approach. My animations are all generated on the fly, no patterns are stored anywhere. I also put great emphasis into keeping every part of the code in the place where it logically belongs, so I have lots of files and classes. So far it worked out well, we'll see how well it will work with the 8x8x8 cube... The part that writes the data out to the cube is in QBWriter.cpp, in the function QBWriter::sendOutputBuffer(). You'll see there that in the first step I shift all 0s into all the shift registers and then, if there's any non-zero data to be displayed, I first wait for 75 milliseconds (delayMicroseconds (TurnOffLatency); //Wait for everything to turn off). this is a software fix to get rid of the ghosting. I'd like a hardware fix though
void QBWriter::sendOutputBuffer () const
{
//To get around the ghosting introduced by the slow turning off of the cathode columns, we first turn everything off and wait a little
digitalWrite (PIN_SS, LOW); //Start transferring data
for (byte i = 0; i <= N; ++i)
{
SPI.transfer (B00000000);
}
digitalWrite (PIN_SS, HIGH); //Done transferring data
if (isOutputDataNonZero ())
{
delayMicroseconds (TurnOffLatency); //Wait for everything to turn off
//Then we push out the contents of the output buffer to the LED cube
digitalWrite (PIN_SS, LOW); //Start transferring data
for (byte i = 0; i <= N; ++i)
{
SPI.transfer (mOutputBuffer[i]);
}
digitalWrite (PIN_SS, HIGH); //Done transferring data
}
}