Mysterious LED problem...could use some help

[Strada916]

why have you used FETs? Why wouldn't everyday transistors do the job. All the matrix boards I have seen use the darlington transistor ararys. and descete transisotors.

[KTP]

why have you used FETs? Why wouldn't everyday transistors do the job. All the matrix boards I have seen use the darlington transistor ararys. and descete transisotors.

 Everyone I know is using some form of packed channel driver chip, so I went that route too with the Allegro for the column drivers.  I think all of the serial shift register type of led driver chips now use fets...at least in the 16 channel models.

As for why I used fets in the row drivers....dual 2.9A, 0.200 ohm in a so8 package, dissipating less than 300mW at max row current.  A bipolar part with 0.6V drop would dissipate nearly a watt at the same current.  But then again...I do seem to be having some problem that is related maybe to the fet drive....

[dcel]

But then again...I do seem to be having some problem that is related maybe to the fet drive....

     Try the pull down resistor yet? It solved my problem and I know why now from codeboy2k's post explaining the capacitive nature of the LEDs. There is an intrinsic capacitance on FET's as well. With no load after the voltage falls below the LEDs turn off voltage, there is nothing to bleed off that stored energy, hence that "afterglow". You may want to put a pull up resistor on your n-chan drain as well so its not floating.

     In my troubleshooting, I put an incandescent lamp in parallel with the LED lamp and that made the channel turn off hard. Uhm... interesting, threw a 100R in with same hard off result. I experimented with increasing resistances and found for my app, that 100K was sufficient to turn the fet off hard at 1ms or less. Good enough for me.

     I had been scratching my head and searching the 'net for a cause and solution for a month and that is whats great about being on this blog,   I had already found the solution to my problem, just not the root cause, but now I know what the problem was, thanks to codeboy2k.

Thanks

Chris

[KTP]

     Try the pull down resistor yet?

I added 1k pulldown to the drain of each Pfet row driver mosftet.  This had the effect of making the problem slightly better in some area and slightly worse in other areas (strange).  This was a few days ago and I was constantly trying different things so my memory may be a bit fuzzy on how much better or worse it was...I just know it did not fix the problem like I thought it would at the time.

I have not added pullups to the row drivers...a bit more problematic here since the drivers have current limit circuitry inside the serial shift register chip and a pullup will steal a fair amount of power (and I really don't want a solution that has me adding 72 resistors!)

Still think scoping is going to be the way out of this...unless we encounter Heisenburg...

[Psi]

Write a function that checks if one of these flickering LED is "ON" by checking the raw state of the output pins. If the led is ever on flag this by setting another output or something. (You may also want to check the state of the pin direction,  output vs highz and flag if it's not what its supposed to be)

Put this function all over your code, after each step.

Display your test pattern or whatever (with an exclusion for this led, so it should always be off).
When you see this particular led flicker check if the function has been tripped.

This should tell you if its a software issue.


I had a similar led matrix flickering issue in one of my projects and it turned out to be an issue with the order of my I/O remapping. I had a few columns and rows on the same mcu port and it required some intelligent code to make sure steps occurred in the correct order.

I also seem to remember that i had an issue where the off state mattered, i can't remember which way around it was, but i think there may have been a difference between having..
led off = anode low & cathode low
  vs
led off  = anode high & cathode high

Probably current feeding back through other leds, but this was a while ago so i could be remembering wrong.
This was five 7x5 led arrays driven directly from the i/o ports. So it was a little different to your design with drivers.

[dcel]

I added 1k pulldown to the drain of each Pfet row driver mosfet.  This had the effect of making the problem slightly better in some area and slightly worse in other areas (strange). 

Well, it seems that you have a mystery there. Keep us posted on what you find out, I would really like to know.

Good luck...

Chris

PS Enjoy using that new scope when it arrives.

[KTP]

Thanks Psi and Dcel.  I will check the software, although single stepping through the code never shows an LED on that should have been off.  Still best to double confirm it is not a software problem.  It is amazing how fast the software guys blame us hardware guys...when I finished the 3rd board and powered it on, one of the leds only had the red and green element on, so my wife immediately claimed I had made a bad solder joint.  Turned out she had just made a change in the code the night before that caused this 

So three boards soldered with thousands of tiny connections, zero mistakes....at least I can do something right.

[KTP]

Going back to the idea that the PN junction capacitance of the LEDs is at the root of my problem, I have thought through a bit more the path of the current and maybe why adding the resistors on the pfet drains did not help the problem much.

In the attached simple schematic, with two row drivers and one column sink driver shown, I have included C1 and C2 to represent the junction capacitance of the LEDs.  Taking the case where D1 should be on and D2 should be off, with the rows switching at 540hz, I see that when M1 is conducting, C1 will charge to about 3.2V (the LED voltage drop).  At this time M2 is off.  When M1 goes off and M2 goes on, C1 is still has 3.2V across it.  The column driver M3 is off (high Z) because D2 supposed to be off, but D2 still has V+LED applied to it's anode.

My theory now is that C1 is creating a virtual ground at the cathode of D2 while C1 maintains it's 3.2V charge.  This puts enough voltage drop across D2 to cause it to turn on for a brief period.  I calculate that if C1 is 50pf, then using I = C * dV/dt, 1uA could be supplied by C1 for 25us before C1 voltage has dropped by 0.5V.  I have already seen that 1uA is enough to cause the amount of light from the LEDS I am seeing.

Adding the resistors to the drain or making the high side driver push/pull just causes the virtual ground created by C1 to go negative, since capacitors cannot change value instantly.  Thus D2 would have an even higher voltage across it as C1 drives its cathode below 0V.  I *think* I actually saw this during one of the scope probings with the Rigol DS1052A but I dismissed it as noise 

Does this seem to make any sense?

Here is the schematic for reference:

[Strada916]

Whats the refresh rate of the panel ??

Maybe slow it down a little, might get rid of some of the parasitic capacitance.

[amyk]

Whats the refresh rate of the panel ??

Maybe slow it down a little, might get rid of some of the parasitic capacitance.

Along the same lines, have you tried using interlacing and halving the refresh rate? Instead of scanning rows 0, 1, 2, ... 10, 11, do 0, 2, 4, .. 10, 1, 3, 5, ..., 9, 11. You could try even higher ratios, like 3:1 or 4:1, with correspondingly lower refresh rates, which might give more time for the drivers to recover.

The simplest workaround would be a suitably translucent cover over the panel, to block out the dim LEDs but allow the ones that are really on to show.

[dcel]

     There is more capacitance involved than just the LEDs. I read the data sheets, the p-chan has an output capacitance of 80-100pf @ 4.8vdc, In your OP, you state 300pf gate cap at 4.8vdc, acording to the data sheet that figure should be 100pf, for the the FDS9953A. There is no info for the output fet of the Allegro A6282 chips. So, for simplicity, call it 100pf output capacitance and I couldn't find a gate rating either. I dont think that the gate capacitance really has anything to do with the problem. I think that the output capacitance and the LED capacitance are adding to create the problem.

Ok, lets add this up, there is 150pf on each LED and they are all tied together from the Allegro A6282 drain, add say another 100pf output capacitance , and now your at 150pf X 3 = 450pf + 100pf = 550pf.

Going back to the idea that the PN junction capacitance of the LEDs is at the root of my problem, I have thought through a bit more the path of the current and maybe why adding the resistors on the pfet drains did not help the problem much.

In the attached simple schematic, with two row drivers and one column sink driver shown, I have included C1 and C2 to represent the junction capacitance of the LEDs.  Taking the case where D1 should be on and D2 should be off, with the rows switching at 540hz, I see that when M1 is conducting, C1 will charge to about 3.2V (the LED voltage drop).  At this time M2 is off.  When M1 goes off and M2 goes on, C1 is still has 3.2V across it.  The column driver M3 is off (high Z) because D2 supposed to be off, but D2 still has V+LED applied to it's anode.

My theory now is that C1 is creating a virtual ground at the cathode of D2 while C1 maintains it's 3.2V charge.  This puts enough voltage drop across D2 to cause it to turn on for a brief period.  I calculate that if C1 is 50pf, then using I = C * dV/dt, 1uA could be supplied by C1 for 25us before C1 voltage has dropped by 0.5V.  I have already seen that 1uA is enough to cause the amount of light from the LEDS I am seeing.

Adding the resistors to the drain or making the high side driver push/pull just causes the virtual ground created by C1 to go negative, since capacitors cannot change value instantly.  Thus D2 would have an even higher voltage across it as C1 drives its cathode below 0V.  I *think* I actually saw this during one of the scope probings with the Rigol DS1052A but I dismissed it as noise 

Does this seem to make any sense?

Yes, and I think you did see it on the scope! Break out the Rigol and post what you find. I reviewed your video of the problem and I can see that all three leds, RGB, are glowing at one point. What LEDs are you using? Are they common cathode? I've modeled the circuit and I can't seem to understand where the problem is exactly, but can see why adding pull up/down resistors didn't help.

Chris

[KTP]

   
Yes, and I think you did see it on the scope! Break out the Rigol and post what you find. I reviewed your video of the problem and I can see that all three leds, RGB, are glowing at one point. What LEDs are you using? Are they common cathode? I've modeled the circuit and I can't seem to understand where the problem is exactly, but can see why adding pull up/down resistors didn't help.

Chris

Wow thanks Chris!  You didn't have to go to that much trouble but I appreciate it.  I don't have great info on the RGB LEDs unfortunately...they are from the ebay china link I posted about on here several months ago...$50 for 1000 on a reel.  The cheapest I could find elsewhere were $0.30 to $0.40 each.  In their favor, I have now soldered up three boards, so 432 LEDs and have not had one bad one.  Of course the boards have been running for only 40 or 50 hours total so far.

My Agilent x3024 arrives today, so I will use that later today to dig into this and post what I find.

[KTP]

In the middle of hooking up the x3024 scope to the RGB board...so annoying that just a 1Meg scope probe makes the led come on.  I guess 1Meg to ground is a decent conductive path for these silly super efficient leds.  Grrr.

As soon as I figure out how to save a waveform I will start posting some pics.  I am starting to have some serious doubts that this problem is going to be an easy fix...I bet it will turn out I need 10K pullups on every low side Allegro driver (72 of them).

Who suggested just using a diffuser and living with the problem?  Smart man...

[amyk]

Who suggested just using a diffuser and living with the problem?  Smart man...

I learned of that trick from some cheap Chinese LED matrix boards.

[dcel]

In the middle of hooking up the x3024 scope to the RGB board...so annoying that just a 1Meg scope probe makes the led come on.  I guess 1Meg to ground is a decent conductive path for these silly super efficient leds.  Grrr.

Is it turning on the FETs? And why?

As soon as I figure out how to save a waveform I will start posting some pics.  I am starting to have some serious doubts that this problem is going to be an easy fix...I bet it will turn out I need 10K pullups on every low side Allegro driver (72 of them).

Waveform pics will tell volumes, that will help alot. Have you read the manual yet?
Along with the resistors, you may also need 72 diodes if my suspicions are correct!

Who suggested just using a diffuser and living with the problem?  Smart man...

With the possibility of adding resistors AND diodes, I'd start looking for some diffused white plastic! 
Funny as that is, it still doesn't fix the problem, not saying your design is flawed, but if its worth doing, do it right. I as well as you are learning from this thread, so lets figure out the problem.

Chris

[KTP]

In the middle of hooking up the x3024 scope to the RGB board...so annoying that just a 1Meg scope probe makes the led come on.  I guess 1Meg to ground is a decent conductive path for these silly super efficient leds.  Grrr.

Is it turning on the FETs? And why?

No, I don't think it is turning on the FETs.  I think the 1Meg to ground scope load is just providing a discharge path to ground for the particular low side of an LED I was probing.  I was trying to look at the voltage across an LED by using one channel on the anode and another on the cathode, and triggering off the digitial row and column channels.  It was just a mild rant that these LEDs can come on (very very dimly) with just 1uA of current.  Probably need a totally isolated diff. probe...could hack something together with a inst. amp that would work at these lower frequencies and voltages....

With the possibility of adding resistors AND diodes, I'd start looking for some diffused white plastic! 
Funny as that is, it still doesn't fix the problem, not saying your design is flawed, but if its worth doing, do it right. I as well as you are learning from this thread, so lets figure out the problem.

Chris

I hear you.  It is worth doing right, and it makes me feel quite stupid that I can't see the easy solution to this problem.  Will be posting some pics today, I figured out the save waveform, you just hit "save".   

[enz]

In the middle of hooking up the x3024 scope to the RGB board...so annoying that just a 1Meg scope probe makes the led come on.  I guess 1Meg to ground is a decent conductive path for these silly super efficient leds.  Grrr.

As soon as I figure out how to save a waveform I will start posting some pics.  I am starting to have some serious doubts that this problem is going to be an easy fix...I bet it will turn out I need 10K pullups on every low side Allegro driver (72 of them).

Who suggested just using a diffuser and living with the problem?  Smart man...

The X-3024A should be delivered with the Agilent probes N2863B (mine was). These are 10:1 passive probes with 15pF and 10MegOhm, not 1MegOhm. So the probe impedance shoudn't be a problem here.

[KTP]

In the middle of hooking up the x3024 scope to the RGB board...so annoying that just a 1Meg scope probe makes the led come on.  I guess 1Meg to ground is a decent conductive path for these silly super efficient leds.  Grrr.

As soon as I figure out how to save a waveform I will start posting some pics.  I am starting to have some serious doubts that this problem is going to be an easy fix...I bet it will turn out I need 10K pullups on every low side Allegro driver (72 of them).

Who suggested just using a diffuser and living with the problem?  Smart man...

The X-3024A should be delivered with the Agilent probes N2863B (mine was). These are 10:1 passive probes with 15pF and 10MegOhm, not 1MegOhm. So the probe impedance shoudn't be a problem here.

Right.  I realized that a few minutes after posting..nevertheless, when I place a scope probe on the low side of a LED element that is supposed to be off (and in this case is), it comes on very dimly.  The impedance of the probe even at 10:1 seems to be providing a current path for the LED cathode when the anode row is switched to 4.8V.  Stupid LEDs probably work down to 0.1uA or something.

I was digging around the junkbox for a large area photodiode I used to have, but can't find it (typical).  I had the thought of making a photon tube  to place over a LED under test, then monitoring the photodiode with the scope.  This would be a way of making sure the scope was not loading the ciruit.  Probably I would have had to build a amplifier circuit for the photodiode though...as we are not talking much light.

[KTP]

Well, here are a few images from my first attempt at probing with the X3024 scope.  In two of the pictures, I tried a 10K pullup on the drain of the nfets (LED cathode) which did seem to get rid of the problem, but I am not 100% sure it didn't make the problem worse in other areas).

I monitored the voltage across an LED cathode and anode in the matrix where the LED in the column above it was on and this LED was supposed to be always off.  The LED was very faintly on.  The yellow trace represents the LED anode, which is connected to all of one row of LED anodes and to the drain of a Pfet.  The green trace represents the LED cathode, which is connected to all the LEDs in that column and to the drain of a Nfet inside the Allegro driver chip.  The difference between the yellow and green trace is thus the bias across the LED.

The blue trace represents the gate drive to the row Pfet of this LED.  The pink trace is the blanking (unused) output of the 3 to 8 decoder that is driving the Pfet row gates.  Thus when the decoder goes from 111 (ouput 7, unused) to 001, the row gates go from all off (high) to row 1 on (active low).  You can see that the Pfet gate of row 1 is taking about 60ns to go fully on (again, this is the blue trace).

The data lines at the bottom are the serial shift register clock (D7) and output latch (D6) of the Allegro chip.  Hmmm...since it does look like we are latching before the gate has gone fully at row 1, I wonder if the gate of row 0 is taking 60ns to go fully off...might check that.

[dcel]

OK, first off, I have not been to sleep yet today (work nights) so I may not be completely in my right mind but I'll try anyways.

Second, SWEEEEEEEET Scope! You gotta be lovin' it.  I just bought a Rigol DS1102E and I'm happy with it, does what I need and $4000 is a far cry from $400!

As you probably already have come to the realization, the 72 pull-up resistors have fixed half of the problem. Sorry to be the bearer of bad news, but, you will also need pulldown resistors on the drain of the pfets. In the image Scope_3, the Yellow trace = pfet drain should be low until the low pulse on the blue trace = pfet gate turns the pfet on, where it goes high like it should. The gate goes high and the pfet should go low, But it never really goes low, its floating, and the pink pulses are slowly bleeding that charge off until the nfet drain goes low and it almost gets it down there.

I'm tired and brain is failing, but, you see where I'm going here, right? All that capacitance is holding the pfet drain high and there is nothing there to pull it low, where it should be.

I'll check back after sleep, g'nite...

Chris

On edit: Repair mindless ramblings, add image.
The light blue is what the yellow trace should look like.

[Niklas]

Perhaps this is solvable with a slight modification of the multiplexing software.
1 - Is every P-channel MOSFET activated, even if no LEDs in that column should be lit? If yes, change it so that they only turn on if needed for that column.
2 - Turn off the P-channel column MOSFET a short time before the corresponding N-channel row MOSFET(s) are turned off. Perhaps this will discharge the capacitance enough. When you barbecue with gas you shut the valve on the bottle first (P-channel MOSFET) and let gas that remains in the tubes burn off (discharge via N-channel MOSFET).

[amyk]

Perhaps this is solvable with a slight modification of the multiplexing software.
1 - Is every P-channel MOSFET activated, even if no LEDs in that column should be lit? If yes, change it so that they only turn on if needed for that column.
2 - Turn off the P-channel column MOSFET a short time before the corresponding N-channel row MOSFET(s) are turned off. Perhaps this will discharge the capacitance enough. When you barbecue with gas you shut the valve on the bottle first (P-channel MOSFET) and let gas that remains in the tubes burn off (discharge via N-channel MOSFET).

A short while ago I suggested using an interlace, which would allow reducing the refresh rate by at least half. That gives double the time for the charge to dissipate.

[Niklas]

Perhaps this is solvable with a slight modification of the multiplexing software.
1 - Is every P-channel MOSFET activated, even if no LEDs in that column should be lit? If yes, change it so that they only turn on if needed for that column.
2 - Turn off the P-channel column MOSFET a short time before the corresponding N-channel row MOSFET(s) are turned off. Perhaps this will discharge the capacitance enough. When you barbecue with gas you shut the valve on the bottle first (P-channel MOSFET) and let gas that remains in the tubes burn off (discharge via N-channel MOSFET).

A short while ago I suggested using an interlace, which would allow reducing the refresh rate by at least half. That gives double the time for the charge to dissipate.

My idea with point number 2 was more like actively draining out remaining charges via the LEDs themselves via the N-channel MOSFETs instead of just dissipating the stored energy. Perhaps the draining phase can be improved by splitting up into two parts with some and then all N-channel MOSFETs as follows:

A - Turn off the P-channel MOSFET, let the N-channel MOSFETs that were on be on
B - Wait for a short time (us)
C - Turn on all N-channel MOSFETs, regardless of previous row state, to drain
D - Wait for a short time (us)
E - Turn off all N-channel MOSFETs
F - Wait for a short time (us)
G - Go to the next column

[KTP]

We tried something similar to what you are suggesting a few days ago.  We turned off the row Pfets, left the column Nfets on for about 1uS, then turned the Nfets off, loaded in new data, turned the Nfets on, then switched the row Pfets on to the new row.  Didn't help.  At this point though we have tried so many things that it is getting fuzzy.  I should have kept detailed records of each test and result, but I was so sure the next thing would fix this I didn't bother.  I am ashamed. 

Right now I am going to try and find that photodiode.  I would like to be able to non-contact probe any LED without having to solder wires to it, and this would elminate any loading effects by the scope probe as an added benefit.  I don't know what signal I will get out of the photodiode at the end of a opaque tube placed over a LED under test, but possibly I could add a preamplifier before the scope.  One thing this might show is exactly when the LED is emitting light.  It is unclear from the channel A - B measurements across an LED..I see around 2V sometimes across an LED that should require 3.2V...but I do see nanosecond spikes that might be 4V difference or so.

Thanks again for the suggestions.

[KTP]

I did some tests on the green element of the RGB LED using the waveform gen on the x3024 in pulse mode.

I aimed at getting the same light level as in the problem LEDs when the matrix is running.

All of these tests were done with a 220 ohm resistor in series with the LED.

4V across LED, 50ns pulse, 540hz waveform produced the same amount of light

3V across the LED, 150ns pulse, 540hz waveform produced the same amount of light

2.5V across the LED, 300ns pulse, 540hz waveform produced the same amount of light

2V across the LED, 250us pulse, 540hz waveform produced the same amount of light

Really shows that it doesn't take much to make these things come on.