LED Cube Ghosting

[wigman27]

Hi,

I have just finished building an 8 x 8 x 8 LED cube from instructables.

I love it, it works really well, except for some ghosting as you can probably see in this video.

http://tinypic.com/r/2jwjuo/5

It is driven using an ATmega32A and then multiplexed, Each vertical column is joined together to make an anode channel and each layers cathodes are joined together. There are 64 anode channels and the 8 cathode channels that are controlled directly from the mega through two 2N2222 transistors in parallel per layer. I don't think its software related as number of people have used it without issue. The pull-up resistors (R20 to R28) are 4.7k each, which I think may be the issue but its not happening on all layers, just some as you will see.

I would really like to see what you think maybe causing it, I'm still a little new at Micros and flip flops so I would really like some ideas.

Thanks again

[Paul Price]

Maybe you are just seeing reflections of the lit LED diodes bouncing off the unlit ones.

Your schematic shows clearly the resistors used in driving the LED multiplexing scheme, but not the resistor values.

[wigman27]

Maybe you are just seeing reflections of the lit LED diodes bouncing off the unlit ones.

Your schematic shows clearly the resistors used in driving the LED multiplexing scheme, but not the resistor values.

Hi Paul,

No, it's not the reflections, initially I thought that but it seems to be getting worse. Which resistors in particular are you after? The pull ups, R20-R28 are 4k7 each

[MacAttak]

It kind of looks like your darlingtons for the layer current sinking aren't driving properly.

Why didn't you just use a darlington array chip instead of all those 2222 transistors? A single chip can replace all of those transistors and associated gate resistors. That's 31 extra parts on your BOM that you don't need.


Have you run a test pattern while watching the layer select signals on a scope?

[C]

Hi wigman,

I have found that the best place to start when trouble shooting a problem is to start at the start, and work your way forward.
One thing to keep in mind is that things take time to happen,
Looking at your circuit I see that port C controls the transistors. A 0 for off and a 1 for on and it takes some time for that collector to change.
I have seen what I would call poor programming practice in some code. So I would start with the code to verify that it is good.

In your display update code,
Keeping time in mind, One of the very first things that should happen is setting all bits of port C to 0 to get that transistor to start turning off. Like wise one of the very last things should be setting port C to have one of it's bits high. In between these two steps is where you should change the data actually driving to the other side of the matrix.
Things to look for,
Code that directly effects Port C should only be in the initialization section and display update code. Find any port C use any place else you may have found a problem.

For an example for you to follow, You may have code like I describe next.
 I have seen some code that was written with the thought that only one bit could be on when you start a display update. The way some code is written it only changes one bit of port C based on what bit it finds on a test of port C's bits. The problem is that any code that changes port C anywhere in the program could cause your Ghosting. If the code is written in this manner,  you have 8 tests of the bits in port C.
 Instead of turning one bit off, Write a 0 to port C first thing. after the bit test of port C to keep your code changes to a minimum. At this point you want all bits off, make sure. If this change makes any difference to the display, you probably have other software problems.
 Look at each of the 8 tests and have the turn on bit sent to port C at the very last of each of the tests sections or a common section after all the tests. In between the two writes to port C update the other side of the matrix.
One problem you might find is that the update of the other side of the matrix uses port C's bits to determine what to update. If you think about it, all bits of port C should be 0 while the update happens.  What you have is a new transistor on with old data displayed until the update is complete or the old transistor on while changing to new data. A ghost. An easy fix would be to pass a value from the 8 tests. 

Now use the same idea to look at the other side of the matrix. Is some section of code other then display update messing with that display?
 
After looking over the code good and if your good at changing the display, make up some test patterns to display. The test patterns will help with checking out the hardware.

C

[Paul Price]

If it ain't hardware then it is your code.

A quick way to see what you are really doing is to connect a debounced switch to an input on your MCU to ground, add a pullup resistor and single step your program (a simple switch pause subroutine that is called in each multiplexing code step)through the lighting of all rows and columns. You should see the problem and the exact point of your code that is causing it.

Sometimes this is much easier than going over and over trying to find a subtle code error, a "blind spot" in your perfect code that you might be missing.

Alternatively you could add a sub that is called the same way but introduces a .3-sec delay as each multiplex state is switched.

If you using an extraordinarily high multiplex freq. then this could cause the effect. You don't want to multiplex the transistors in the MHz, a few kHz will do.

If you are using shift regs to shift in row or column values make sure the LEDs are blanked during the shift reg update clocking to the desired result and use as a shift clock as fast as the setup and hold time on the S.Reg. can stand.

[MacAttak]

Also, there may be a timing problem with the CLK on your latches. I would not drive those CLK signals directly from your 138 decoder. At least use the enable pins of the 138 to bring down CLK on all latches while you shift in new data. I'm not sure which pin it would be in your schematic (the G1/G2A/G2B names aren't familiar to me, should be /E1, /E2, and E3). But basically, disable the 138 output, write new data to the output port, write new address select bits, give it time to settle, then enable the 138 again with a short pulse to latch it cleanly.

Right now you are writing new data and address select, and never letting anything settle, but if the address select happens to settle before the port bits are settled, then the next layer will latch to invalid data.

[C]

I would say that MacAttak is correct. I have often seen a decoder like the 138 ripple through a bunch of different outputs when it is constantly enabled.

No great cure can happen in software as is. Might move it to one spot most of time but no real cure.
I see two leds and one btn1 on that connector, I would suggest lose of one to use as an enable signal for the 138

When you have a connection from one of the three above, you want to write the data and give it a little time to settle then change the 138 enable.
C

[wigman27]

Wow! Awesome replys, thank you very much!

In response to why I didn't use a darlington array, it was mainly because I am still relatively new at electronics and wanted to build it exactly as they had it, see how I went then make improvements on a new controller of my own from what I had learnt in the process. I think I will investigate a good darlington array to use and replace it anyway.

It certainly sounds that it could well be the software as well. C programing language and mc programming is entirely new to me. To be honest, it's doing my head in a little at the moment as to how it all fits together. What I might do is have a good read up on it and investigate how multiplexing works then have another good look at the code.

Can you suggest a good reference to learn about mc programing and multiplexing? I am a web developer as well, so programing language isn't entirely unfamiliar but C certainly is.

Thanks again, I really appreciate your support. On the hunt for a darlington array :-)

[Paul Price]

From an artistic or esthetic viewpoint, the ghosting makes the object more interesting to view, at least for me.

Don't make it a fault, make it a feature!

[wigman27]

From an artistic or esthetic viewpoint, the ghosting makes the object more interesting to view, at least for me.

Don't make it a fault, make it a feature!

HAHA love your thinking Paul! There is always room for a positive spin!!

[wigman27]

AAAAHHHH Transistors!

OK, Please if you wouldn't mind offering some advice on transistor arrays.

Each LED is drawing 18mA, there can be 64 on at anytime through any transistor (one at a time) so that is a required maximum collector current of 1.152A (please correct me if I am wrong)

From what I could find, there aren't any Octals out there capable of taking more than 500mA Ic. So, if I were to use two quads that would be better than what I currently have.

As I haven't done a lot of transistor selection before and never used quads, could I please confirm that the ULN2066B, ULN2070B or ULN2076B on this datasheet would suit my purpose.

Also, from the way I read the schematic the base resistors aren't required as they are internal, am I reading it incorrectly? If I am then I will need about 2mA base current to achieve the result?

Would they require heat sinks? another thing I haven't done a whole lot of.

Thanks again for your help, now to start playing with the code.

Lee

[C]

If you are using the software from instructables.
I do not see a ghost from outputs enabled during update in the software.
If the 138 does not cleanly change states, the bounces would cause the wrong latch to latch current data
sequence is
all layers off  (transistors)
OE disable (574)
loop
  latch data
  138 address lines
in loop
OE enable (574)
layer on

NOTE: The 74HC574 has current limits. The data sheet I found
IO          output current VO=?0.5 V to (VCC+0.5V)    -±35 mA
ICC        supply current - +70 mA
IGND     ground current- ?70 mA
70 mA / 8 led on =   ___   

If you have  18mA a led then you are over limit for 74HC574

Would help knowing what resistors values you are using

[Strada916]

AAAAHHHH Transistors!

OK, Please if you wouldn't mind offering some advice on transistor arrays.

Each LED is drawing 18mA, there can be 64 on at anytime through any transistor (one at a time) so that is a required maximum collector current of 1.152A (please correct me if I am wrong)

From what I could find, there aren't any Octals out there capable of taking more than 500mA Ic. So, if I were to use two quads that would be better than what I currently have.

As I haven't done a lot of transistor selection before and never used quads, could I please confirm that the ULN2066B, ULN2070B or ULN2076B on this datasheet would suit my purpose.

Also, from the way I read the schematic the base resistors aren't required as they are internal, am I reading it incorrectly? If I am then I will need about 2mA base current to achieve the result?

Would they require heat sinks? another thing I haven't done a whole lot of.

Thanks again for your help, now to start playing with the code.

Lee

The way Multiplexing works, is only one LED is on at any one time (This is the most common method, there are others). It all happens so fast you can not see one going off and the next turning on. This is called Persistence of Vision. (POV). The UL230x chips can handle 500mA on one output. I do not think you will be placing 500mA on one LED.  Current draw more than likely will be seen as an overall consumption as the meter can not update that fast. Check it out with a scope if you have one.

Take up your own advise and research multiplexing and Charlie-plexing. Some really interesting stuff. Especially what the brains sees and what is actually happening.

Research the code and find out if it is actually is lighting one LED at a time or not.

[wigman27]

NOTE: The 74HC574 has current limits. The data sheet I found
IO          output current VO=?0.5 V to (VCC+0.5V)    -±35 mA
ICC        supply current - +70 mA
IGND     ground current- ?70 mA
70 mA / 8 led on =   ___   

If you have  18mA a led then you are over limit for 74HC574

Would help knowing what resistors values you are using

Hi C,

Thanks again for your reply, As far as I can see the 74HC574 allows 35mA per bit and 8 pits per device, is that correct or am I reading it wrong? I only have one LED per bit, there are 8 74HG574s in total with 8 bits each, so one per LED, so each bit will only see 18mA as far as I can tell. Please correct me if that's not true.

The LED load resistors are 100 Ohm each and 64 of them They are 5mm white LEDs, I am using 4k7 pull up resistors for the 2N2222s and a 1k base resistor per transistor.

The way Multiplexing works, is only one LED is on at any one time (This is the most common method, there are others). It all happens so fast you can not see one going off and the next turning on. This is called Persistence of Vision. (POV). The UL230x chips can handle 500mA on one output. I do not think you will be placing 500mA on one LED.  Current draw more than likely will be seen as an overall consumption as the meter can not update that fast. Check it out with a scope if you have one.
 

Hi Strada916,

Thanks mate, from my understanding, the layers are only switched on once all the multiplexing is complete for all the anodes on that layer. So the cathode layers (transistors) are all turned off, then all anodes for layer 0 are multiplexed (up to 64) then the cathode layer is switched on, then off and the the anodes for layer 1 are multiplexed then the cathode layer switched on and so on, so I believe the transistors are switching 8 times per "pattern" not 512 times. So therefore the layer transistors are switching 64 x 18mA.

Do you think the ULN20xx will be suitable?

I certainly will be reading a lot over the next little while I am sure.

Thanks again

Lee

[C]

Hi Strada916
  you could think of this cube as having 8 digits(here levels, the hight of the cube) so just 8 time slots. If thinking digits, this display has 8 X 8 segments per digit. If you look at videos, all of a level being on is common.
======
wigman:

While the current capability of one output may be high, I Think you will find that you have to keep in the package limits of the chip.
70 mA / 8 led on =   ___
I find 70ma max to device some places and 50Ma others.  Get a data sheet from the mfr. as there are differences. You also have heat limits of the chips.

In case you do not know it, one way they test how long a chip will last is running samples at high temp.
long time ago part of my job was high temp testing. I have seen things in dip packages still working when the plastic dip looked like it was a wafer on board construction. Had some OPPS, when something got the high temp test was built using lead based solder. In general if you want something to last, keep it cool, stay away from any limits in data sheet, and pretend that there is no protection in chip. A circuit that used or counted on having on chip Protection failed sooner at high temp.
     
The mpu has some good current capability per pin. Better check its package limits.
So what do you compute for the pins of the AVR.

I like nice easy to read data. If is was doing this, I would have one version of the drawings with extra labels stating that  pin __ on connector is ___  , saves time in long run

My lazy side puts part of this documentation in spreed sheet so it can do the math.

I think you will hit the package limits for a lot of chips. A quad pack might get you under limits.

If building led cube(s) was my thing, and I thought there might be more then one, I think I would use three boards.

One thing not addressed is EMI, See what happens to a cheap AM radio near the cube. Would not be surprised a lot of noise on radio.

C

[C]

If you are going to the effort to fix some of the problems, might it not be a good idea to fix all of them so you can know "I did that right"?

Might think of a swap where you put the mpu board on top of the other board. Would allow you to move btn1 and two leds and free up 3 on connector. One could be a proper enable for the 138.

C 

[MacAttak]

ULN2803 is probably a better choice. This is used frequently in these kinds of projects for this purpose. It has eight stages, but you can parallel them if you need more than 500mA per driver. If you pull up the datasheet on the 2803 you will see that it is pretty much exactly what that whole section of your schematic looks like, plus with some added protection diodes. But all in one neat package.

I think the darlington design is the smaller issue though... the latch clock signal is where the main problem lies (where you are using the 138 to drive the latching clock, as discussed previously).

[C]

MacAttak
Have not studied the data sheet,
how well do the ULN28xx handle load sharing?


The MPU still has a couple pins left unused. If using software from the source listed, Software looks very easy to change to get an enable signal for the 138.
So I see an extra wire between the two boards or moving that button with 2 leds to free three pins.
Did I miss an option for this part?
 C

[mariush]

You have to picture your 8x8x8 cube as a 8 separate  8x8 leds squares.

Let's go to the basics and work on just a single 8x8 square of white leds.

You can put these in 8 columns of 8 leds and connect the anodes together, so now if you send voltage through a resistor (to limit current) all leds in column would light up if you connect the cathodes to ground.  Now naturally, if you limit the current to let's say 15 mA, if you connect one cathode to ground one led lights up and gets 15 mA, if you connect 2 cathodes to ground, each led gets 7.5 mA, if you connect all 8 cathodes to ground you get about 2 mA through each led.  This is not good.
So your solution is to only light up one led from a column at a time. 
If you connect the cathode of first led to ground, wait a few ms, disconnect, connect second cathode to ground, wait a few ms, and repeat for all 8 leds in column, your eyes would see all 8 leds lit up at the same time.. That's persistence of vision. 
You can also make one led appear dimmer or brighter by changing how often the led is turned on or off.  For example, if you keep each led lit up for 1 ms,  in your 8 led column, each led is lit up 1000 ms / 8 = 125 times a second. If you want a led in a column to appear dimmer, you can just make it light up.. let's say 70 times a second.

Now, you can take the 8 columns of leds and tie the cathodes of each row together. Now instead of 8 anodes and 64 separate cathodes you have 8 anodes and 8 cathodes.
Your microcontroller now has to decide for each row in a column what led is supposed to light, send power to all columns where led is supposed to be on, but only connect the cathode of a particular row to ground.

A transistor array like ULN2803A has 8 darlington transistors and a resistor in front of each transistor in the package. Each transistor can sink 0.5A to ground.  When your microcontroller sends power to the base of a transistor in the package, that transistor turns on and connects the cathode of a row  to ground.  You're only going to have the current of a led, times 8 going through one transistor of the array (0.015mA x 8 = 0.12A).
 
So with 16 i/o pins from a microcontroller, you can use 8 pins to send power to leds (or to a transistor+base resistor which turns on and sends power to each column) and 8 pins to turn on the transistors in the transistor array, one at a time for each column.

You can further reduce the number of pins used by using shift registers. To use a shift register you only need 2-3 pins and you can link shift registers together.
So you can use shift register to get 8 outputs and instead of connecting the column leds (or base resistor of the transistor that powers leds) directly to 8 pins of the microcontroller , connect them directly to the shift register.  Same with the transistor array at the cathodes.
Now your microcontroller only needs 6 pins, 3 for each shift register. The microcontroller shifts  8 bits to first shift register to select columns that have to light up, then shifts 8 bits to select which row is connected to ground.  Then repeat eight times, one for each row.
 
Once you have this done, you can just multiply it for the depth of your cube, eight identical squares. as you can link shift registers together, you have eight shift registers for the columns, eight shift registers for the cathodes of each row in the cube, eight transistor arrays, one for each square.  This way you can light up eight rows at a time, one from each square.

You can further multiplex things by connecting all eight rows cathodes from each square together, but now you can no longer light up 8 rows at a time,  one from each square.
You now have to connect  to ground whole plane (rows 1 from all 8 squares for example), turn on leds for square 1, wait, turn off, turn on leds for square 2, wait, turn off... and so on until you get to square 8. Then disconnect plane and connect to ground next plane (rows 2 from all 8 squares) and repeat.
But with this method, if each led lights up for 1ms, each row will light up for 1 ms, so between the time one row lights and then gets to light up again, about 63 ms pass. 


Here's a very ugly drawing i made in paint on how to do the 8x8 :

 

[MacAttak]

Hmm, thinking about this some more.

Usually, the approach taken when loading an 8x8x8 cube with data is to use an 8-bit wide serial bus. Each wire of the bus feeds the input of an 8-bit latching shift register (you would use 8 latching shift registers, one per column). This lets you fully load an entire 8x8 array of data using only 10 wires (or 9 wires if you are clever and add a 3-bit counter to the design). You need the 8 bits of data, and a serial clock input. The final input, the latching clock, can be the 10th wire or you can use a 3-bit counter which will produce a clock edge for every 8 pulses of the serial clock. Otherwise, you can just drive an extra pin for the latching clock. In either case, the 10 (or 9) pins needed for a serial design is still lower than the 11 pins you are using currently (you have an 8-bit parallel bus plus a 3-bit encoded control signal in your design). You would also normally use three pins for layer selection instead of the 8 that you have used. You only need 3 pins and 3-8 decoder to enable one darlington layer at a time. Again, you could be clever here and drive it with a single layer clock signal and a 3-bit counter to feed the layer decoder.

The way you would use the serial bus is straightforward. Make sure that all of the pins in the data bus are in the same port of the microcontroller (ex: PORTA, PORTC, etc). You then push a full 8-bit value to the port, bring the serial clock signal up, wait long enough, then lower the serial clock. Repeat that 7 more times to load the rest of the shift register positions, and then finally raise the latch clock signal, wait, and then lower it. You can do all of this while leaving the output of the latched registers enabled.

This is what pseudocode would normally look like:

Code: [Select]

repeat forever,
  repeat 8 times,
    for each row,
      assign PORT = rowdata
      wait (respect the timing requirements of shift register)
      assign serial_clk = 1
      wait (respect the timing requirements of shift register)
      assign serial_clk = 0
    next row
    assign layer_select_enable = 0 (disable darlingtons)
    assign latch_output_enable = 0 (disable latch outputs)
    assign latch_clk = 1
    wait (respect the timing requirements of latches)
    assign latch_clk = 0
    assign layer_encoded = layer_encoded + 1 (switch darlington array to next layer)
    assign latch_output_enable = 1 (re-enable latch outputs)
    assign layer_select_enable = 1 (re-enable darlingtons)
  next iteration
next iteration
This design allows you to pre-load all of the data for an entire layer, and then quickly latch it all in at once to minimize the frame transition time.

Also, using a 3-bit encoded layer control plus enable signal like this will help clean up the transistor switching a lot. This could easily be contributing to your ghosting problems.

And of course, fewer parts and fewer pins to control is always a good thing.

[MacAttak]

Just to add to what mariush says - you can drive the multiplexing of the cube a full layer at a time, or just one row or column at a time. There are tradeoffs.

Driving a full layer at a time:
  Good - you get 1/8 duty cycle
  Bad - you need to be able to sink a large current, up to 64 times the per-LED current

Driving a row or column at a time:
  Good - low current usage (1/8 the current usage of the other option)
  Bad - only 1/64 duty cycle (1/8 the brightness of the other option)

[mariush]

Just to add to what mariush says - you can drive the multiplexing of the cube a full layer at a time, or just one row or column at a time. There are tradeoffs.

Driving a full layer at a time:
  Good - you get 1/8 duty cycle
  Bad - you need to be able to sink a large current, up to 64 times the per-LED current

You can use a transistor for each row by not linking the cathodes of a layer together.
But you'll have 64 wires going to 64 transistor elements (so you have 8-10 darlington arrays) which may look ugly depending on how you want the cube to look.  Then, each transistor will only sink the current for the 8 leds in a row so well below its maximum.

Alternatively, with ICs like ULN2803A or ULN2003A it's possible to connect several transistors in parallel. So you could use 3 uln2803a for each layer, giving you 1.5A of current handling.

[C]

My thinking is
A lot work and effort has already been spent on what has been  built, so simple changes to get it to work proper. A new design from scratch has a lot of options, but is forgetting all the work already done.
Here the cube has already been built with a lot of work involved. It is a common cathode with each layer having a separate cathode line.

Next in time already spent is the latch board. The already built board for the latches is just missing an enable signal to 138 to cure that problem. It will still have the limited current output. With out rebuilding the cube, a high side switch is needed to increase current capability.
So a one wire fix is possible, and to use existing cable, the easy change is to move switch with 2 leds.
   
On processor board, I do not like the current transistor setup. So something needs done here, I think. With out changes to the cube, the design needs to handle 64 led's current use in a low side switch.


C 

[Strada916]

Going over the schematic, they are relying on the micro outputs to bias the transistors off. Since you have said you are using 4k7 resistors for the 2n2222 I would replace them with 1k. This should turn the transistors on and off quickly, instead of having the lag or ghosting. Have a look at the comments in the project someone also mentions to use lower value resistors.