EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: KTP on July 11, 2012, 04:04:52 pm
-
Me again. I know I take more than I give on here, but maybe one day can make up for that. ;)
I have this very annoying problem right now in what I thought would be a simple RGB led matrix board. The problem is that leds that are supposed to be inactive are very dimly on. This has to be something silly stupid simple that I am just missing but it is driving me a bit crazy. I estimate from experiments with a single RGB led on the green element that the annoying won't-stay-dark leds are only getting about 0.5 to 1 uA. Just enough to see them in a darkish room from a foot or two away.
The 12x12 matrix is split into two 6x12 banks. Discrete P channel, logic level mosfets drive the rows (six total mosfets, each driving one row in each bank) and the column elements are driven by six Allegro A6282 16 channel current regulated sinking drivers (using only 12 of 16 channels). Three chips per bank, each driving either all the red, green, or blue elements.
I have experimented with the turn on, turn off times of the row driver fets, and even added a push pull driver to the rows along with a beefy 150mA gate driver all which made little difference. The leds are being software PWM'd by an Atmel Xmega and tight code...right now hitting the rows at a fairly slow 540Hz and much faster column (for the color control). If I slow things way way down the problem goes away (or at least can't be seen by my eye).
The row drivers are discrete Pfets, FDS9953A, 300pF gate capacitance @ Vgs -4.5V, Rds_on = 200mOhm
The column drivers are contained in the Allegro A6282 chips.
I still need to do some serious scope work, but maybe there is just something too obvious that I am missing. I am at this moment toying with the idea that the leds are acting as capacitors and feeding others even when the pmos row driver is fully off. Or I have some serious inductance, capacitance issues on the board layout. 0.5uA doesn't sound like much...
I have attached a simplified portion of a crude schematic to make things a bit more clear. Thanks ahead for any help or suggestions what to try next.
-
I would guess capacitive coupling through the reverse biased diodes, or leakage current. Try adding some pull down resistors on M1 and pull up resistors on M2 to bias the diodes harder off.
-
I would guess capacitive coupling through the reverse biased diodes, or leakage current. Try adding some pull down resistors on M1 and pull up resistors on M2 to bias the diodes harder off.
Thanks. I have tried adding pull down resistors on M1 which actually made the problem worse in some areas (this was really strange, but maybe explainable if the PN junction capacitance of the reverse biased diodes is passing current at the frequency I am using). The currents in question are so low it is somewhat difficult to try and pinpoint with a scope what is going on (or maybe I just need more experience).
I played around with pullups on M2 on a few pins (there are 72 total channels so doing all of them is not trivial) and it actually made the problem worse also.
-
Try a Pull-Up at the Gate of M1, not M2.
I think M1 doesn't shut off fast enough.
-
Try a Pull-Up at the Gate of M1, not M2.
I think M1 doesn't shut off fast enough.
Thanks for the reply! The board already has a 10K pullup on the gate of M1, and I have tried to increase this to as much as 500 ohms with no difference. I currently drive the row mosfets through a 74AC138, which acts as both a halfway decent driver (+/-24mA), a level converter between the 3.3V atmel ports and the V+_LED voltage, and also reduces data lines from 6 to 3 and ensures only one row at a time will be on (in each bank).
Thinking as you did that the row transistors were not turning off fast enough and for a small amount of time was staying active after the next row's column data was loaded and latched on the A6282, I built a push pull driver capable of 150mA source/sink to drive the gate of M1. I only did this for two rows, but even when only putting data on those two rows I still had the faint led element on problem. You can start to see why this problem is annoying me. :).
-
Did you also try a replacement for the Allegro Driver? For example a simple MosFET with current limiting resistor?
Maybe the problem is the leakage current of the Allegro Driver.
The datasheets says max. 0.5µA maybe...
-
Did you also try a replacement for the Allegro Driver? For example a simple MosFET with current limiting resistor?
Maybe the problem is the leakage current of the Allegro Driver.
The datasheets says max. 0.5µA maybe...
enz, thank you for the replies and for taking the time to read the data sheet, very nice of you.
You have come to the same idea as I, only in 10 minutes instead of a few days :D
I ordered on monday replacement driver chips (STP16CP05XTTR) which conveniently have the same pinout and serial address format as the Allegro parts, but have twice current sink capability at 100mA per channel. The downside is that they are around $1 in quantity while the Allegro is $0.60. I don't know if I want them to fix this or not :)
I have not tried replacing the Allegro part with discrete fets and resistors...there are 72 driven channels, meaning 144 more parts and at least 720 more solder joints (on top of the thousands of solder joints I hand solder under a microscope now). Also, I would need a shift register and latch to implement the serial functionality of the few required data lines to the Allegro parts.
Edit: with a leakage current of 1uA, it is possible the STP16CP05 parts make the problem worse, but at least this might show where the problem is. WTB schmitt trigger LEDs :D
-
Here are two videos, the first just showing two of the boards running (at 1/6 max intensity, which still saturates the camera heh..can't even see PM is yellow on camera). The second video is trying to get a closeup of the LEDs which should never be on. I tried to shield the other light with 1/8" plastic, but you still have to look closely at the first two leds to see the small blink of the red and green element as the ghost and pm pass by. If a column is not on there is no led problem. Other than this issue the prototype worked well... 5V to 15V input, RS485 communication, 6mm max thickness included pcb.
Note these videos are of two boards running side by side. There are only 144 RGB leds per board. Up to 256 boards can be linked together using the RS485 1/8 load drivers (and a crapload of 12V power even with the 93% efficient onboard switcher!). I am NOT hand soldering 256 board! ;D
overall video:
http://youtu.be/P8oh7jHdjBc (http://youtu.be/P8oh7jHdjBc)
closeup of problem:
http://youtu.be/tOfkz1V9WC4 (http://youtu.be/tOfkz1V9WC4)
-
overall video:
http://youtu.be/P8oh7jHdjBc (http://youtu.be/P8oh7jHdjBc)
You have said almost nothing about how you are driving the matrix.
Row and column drivers do not turn on and off instantly. When you multiplex to the next row you need to turn off all columns before for a few us and turn on the required column a few us after. If you don't you will get bleed from one column to the next (swap rows and columns if that is how you are multiplexing).
Maybe you can see this bleed, can't see much on the video. If it isn't bleeding then maybe you are doing something dumb like shifting through the register with the latch enabled.
The faster you multiplex the worse both these effects would be which seems to be the case.
-
overall video:
http://youtu.be/P8oh7jHdjBc (http://youtu.be/P8oh7jHdjBc)
You have said almost nothing about how you are driving the matrix.
Row and column drivers do not turn on and off instantly. When you multiplex to the next row you need to turn off all columns before for a few us and turn on the required column a few us after. If you don't you will get bleed from one column to the next (swap rows and columns if that is how you are multiplexing).
Maybe you can see this bleed, can't see much on the video. If it isn't bleeding then maybe you are doing something dumb like shifting through the register with the latch enabled.
The faster you multiplex the worse both these effects would be which seems to be the case.
My wife is writing the software on the Atmel XMEGA, so I am with you and would much rather blame her (although she is letting me get a MSOX3024A, so maybe I will rub her feet instead :D )
Seriously though, she does have delay before each row switch. I am not sure of the present amount but we have experimented up to several usec. It didn't seem to make a huge difference, but hard to tell with the problem being so small. I will have her add back in more delay between row switch just to make sure the problem is not bleed. I don't touch her code now that she switched from C to assembly (she said the AVR compiler was crap lol. She can write 1000 lines of assembly in about 10 minutes anyway).
Edit: Also I too at first thought she was shifting through the active low latch accidentally and had her check that (plus I scoped it heh heh). I really do think it is hardware at this point....possibly the leakage current talked about above.
-
I have not tried replacing the Allegro part with discrete fets and resistors...there are 72 driven channels, meaning 144 more parts and at least 720 more solder joints (on top of the thousands of solder joints I hand solder under a microscope now). Also, I would need a shift register and latch to implement the serial functionality of the few required data lines to the Allegro parts.
Edit: with a leakage current of 1uA, it is possible the STP16CP05 parts make the problem worse, but at least this might show where the problem is. WTB schmitt trigger LEDs :D
Of course i didn't mean to change all channels to a discrete MosFET. Just a few to try to locate the real problem.
-
Well, this problem does sound rather annoying. I couldn't see much on the vid's, but how well is your power supply decoupling? The drivers will certainly be offset by voltage ripple. It looks like the switching MOSFETs are in the middle of the board and their gate drive might be offset by ripple in the power supply too. (Do correct me when I'm wrong, it is hard to see the layout of your board in de video).
Imho there are two things you can do quite quickly to check some possible problems:
If you have any ceramic (or similar low ESR type) capacitor in the 100nF range you can connect it to the power supply near the LED and/or appropriate driver and check if the bleeding disappears. If it does it is a power supply decoupling problem and you need to design a decoupling capacitor near where you found the most influence. This is most likely to be near the drivers (which are most sensitive to voltage fluctuations) or the MOSFETs (which are furthest away from the actual power supply and sink the most current). Sometimes an already installed decoupling capacitor is the wrong one (100pF instead of 100nF is a common mistake in prototyping).
It might also be interference the gate drive picks up through capacitive or inductive coupling of high dv/dt or high current signals. This will cause small spikes near near the edges of the transition. If so, the ghosting will disappear when you connect a capacitor in the 10nF or so range between the gate and source of the MOSFETs that filters away the spikes. It depends on the frequency and the severity of the problem how much capacitance will work before blanking out the LED altogether, this is something of an experiment. Looking at the specs the MOSFET itself gives approximately 250pF of capacitance so trying 1 - 4,7 - 10 - 47nF might work. Due to the large currents your driver is able to supply a larger value might even be necessary. This is not a solution and should be used for short turn checks to prevent excessive spike currents from flowing for too long.
These are only to check if there are spikes in the signal but are easy to check with the right (leaded) components lying around.
-
Of course i didn't mean to change all channels to a discrete MosFET. Just a few to try to locate the real problem.
Ah, ok...yes silly me. I get all defensive when presented with a chance of messing up a board that took me 12 hours to hand solder heh heh. Doing your suggestion would require either making up a new board, or partial new board...or trying to desolder one of the TSSOP not-very-exposed pad chips on traces that look small to a ant.
The new chips just arrived however! With these different chips with different leakage current, perhaps it will assist in locating the real problem. If not I may do a partial board with your suggestion. Thanks!
-
Well, this problem does sound rather annoying. I couldn't see much on the vid's, but how well is your power supply decoupling? The drivers will certainly be offset by voltage ripple. It looks like the switching MOSFETs are in the middle of the board and their gate drive might be offset by ripple in the power supply too. (Do correct me when I'm wrong, it is hard to see the layout of your board in de video).
Imho there are two things you can do quite quickly to check some possible problems:
If you have any ceramic (or similar low ESR type) capacitor in the 100nF range you can connect it to the power supply near the LED and/or appropriate driver and check if the bleeding disappears. If it does it is a power supply decoupling problem and you need to design a decoupling capacitor near where you found the most influence. This is most likely to be near the drivers (which are most sensitive to voltage fluctuations) or the MOSFETs (which are furthest away from the actual power supply and sink the most current). Sometimes an already installed decoupling capacitor is the wrong one (100pF instead of 100nF is a common mistake in prototyping).
It might also be interference the gate drive picks up through capacitive or inductive coupling of high dv/dt or high current signals. This will cause small spikes near near the edges of the transition. If so, the ghosting will disappear when you connect a capacitor in the 10nF or so range between the gate and source of the MOSFETs that filters away the spikes. It depends on the frequency and the severity of the problem how much capacitance will work before blanking out the LED altogether, this is something of an experiment. Looking at the specs the MOSFET itself gives approximately 250pF of capacitance so trying 1 - 4,7 - 10 - 47nF might work. Due to the large currents your driver is able to supply a larger value might even be necessary. This is not a solution and should be used for short turn checks to prevent excessive spike currents from flowing for too long.
These are only to check if there are spikes in the signal but are easy to check with the right (leaded) components lying around.
Thanks Crumble. There are 100uF ceramic caps (expensive!) next to each column driver chip connected to the V+LED rail and ground and 0.1uF caps also next to each column driver chip connected to the logic supply and ground (these chips use 3.3V logic supply and V+LED is a separate supply). I placed the chips in the middle of the board for ease of routing, because I wanted to only use 2 layers for cheapness (maybe this is biting me in the ... now though). I have a nice ground plane running down the middle underside, but not over the whole board in the matrix section. The logic section is well ground planed.
Spikes on the mosfet gate....hmmm. It could be possible...I will look into that as you suggest, thanks again.
-
To aid in the discussion, here are some closeup pictures of the front and back of the protoboard (yes, I did not clean the flux yet....but it is Kester 186 and shouldn't be a problem). The back is a shot of an unsoldered board. I placed the driver chips in the matrix area also because I have designed the upper logic section to easily break away and fold under the board using headers in the double row of holes in each connecting trace. This way if one wanted to make a huge array the board spacing would work out peachy.
-
A couple of scope traces would be nice to see. That way we can see the delays between the row and column switching and what the edges look like.
-
A couple of scope traces would be nice to see. That way we can see the delays between the row and column switching and what the edges look like.
When my MSOX3024A scope gets here, we will see oodles of scope traces...including exact timing of logic switch events and their analog consequences. I am excited! I know good equipment doesn't fix poor skills, but when I fully learn the new scope ins and outs it should be a great help on mixed signal stuff.
-
Are you sure this is not a software problem? In order to prevent ghosting you need to blank the row/column being driven before advancing the column/row selection line, that way the next row/column is not being driven with the old data even for a fraction of time.
For example, my matrix follows this pseudo-code:
Load Data to Column Buffers
Enable Blanking
Jump to the next Row
Latch Data to Column Latches/Drivers
Disable Blanking
This prevents the previous line from showing up at the next line for a very small time interval. I could be completely wrong but it is possible. =)
-
Are you sure this is not a software problem? In order to prevent ghosting you need to blank the row/column being driven before advancing the column/row selection line, that way the next row/column is not being driven with the old data even for a fraction of time.
For example, my matrix follows this pseudo-code:
Load Data to Column Buffers
Enable Blanking
Jump to the next Row
Latch Data to Column Latches/Drivers
Disable Blanking
This prevents the previous line from showing up at the next line for a very small time interval. I could be completely wrong but it is possible. =)
Yes, we even just tried adding a huge delay.
Load Column data
Blank
Added 5uS delay here, made no diff.
Switch Row
Added 5uS delay here, made no diff.
Latch Column data
Added 5uS delay here, made no diff.
UnBlank
Pretty much exactly what you describe. I think as the DrGeoff prescribed, we will need to submit the patient to the extensive probing of the MSO ;D Stay tuned next week, same bat time, same bat channel.
-
Why don't you temporarily switch off the multiplexing and just illuminate one row or column and see what the adjacent LEDs are doing? This will then tell you if it's a switching problem or a driver leakage current problem.
-
Why don't you temporarily switch off the multiplexing and just illuminate one row or column and see what the adjacent LEDs are doing? This will then tell you if it's a switching problem or a driver leakage current problem.
When you step through the code the problem is not there (just illuminating one row with no row switching).
If no led in a column is ever active, that column never has this problem (just to point out that this would tend to eliminate some sort of board noise causing the problem...or maybe not...I have not had morning coffee yet).
Today I should be able to solder up the 3rd board (if i don't spend too much time on EEVblog) with the new different column driver chips...
-
Try putting a 1k or 10k pull down resistor on the drain of the p-chan fets. I had the same problem with the project I am working on and found that fixed it. Something to do with a minimum load on the p-chan that is the problem with them not turning off completely or not fast enough. They acted like there was a RC timed roll off just at the LED voltage off point. It could be just my application because I am using commercial LED stop/turn/tail lights @ 12vdc.
Might be worth a try...
Chris
-
LEDs have an intrinsic capacitance, from about 20pf to 90pf, depending on the LED. Including the trace series inductance, and a LED string is hard to switch off fast.
You have to turn them hard off, otherwise they tend to stay charged up, especially when you are switching them fast.
That's also why it doesn't show up when you just have one column on. I don't think it's leakage on the board, it's more likely the PFET not turning off fast enough, or or not being fully off, coupled with the LEDs built-in capacitance and the trace inductance maintaining a current flow. The best way to switch off the string is if you can pull it below 0 when off. This becomes more necessary as you switch at faster and faster speeds. Done this way, you reverse bias the capacitance and it will go full off quicker. Otherwise, work on making sure the PFET and NFET are both fully off when switching.
As this diagram shows, LEDs make nice varactors :)
(http://www.edn.com/photo/293/293252-An_LED_s_intrinsic_capacitance_works_in_a_650_mV_LRC_circuit_figure_2.jpg)
-
LEDs have an intrinsic capacitance, from about 20pf to 90pf, depending on the LED. Including the trace series inductance, and a LED string is hard to switch off fast.
You have to turn them hard off, otherwise they tend to stay charged up, especially when you are switching them fast.
That's also why it doesn't show up when you just have one column on. I don't think it's leakage on the board, it's more likely the PFET not turning off fast enough, or or not being fully off, coupled with the LEDs built-in capacitance and the trace inductance maintaining a current flow. The best way to switch off the string is if you can pull it below 0 when off. This becomes more necessary as you switch at faster and faster speeds. Done this way, you reverse bias the capacitance and it will go full off quicker. Otherwise, work on making sure the PFET and NFET are both fully off when switching.
As this diagram shows, LEDs make nice varactors :)
(http://www.edn.com/photo/293/293252-An_LED_s_intrinsic_capacitance_works_in_a_650_mV_LRC_circuit_figure_2.jpg)
I did try putting a nfet along with the pfet on two of the rows in a push pull configuration thinking exactly along the lines you have. My wife then modified the code to only switch between those two rows, and the problem was still there. Note that for this test I also beefed up the driver to the pfet/nfet push pull such that it could drive the gate from 0.1V to 4.8V at +/-150mA.
It seemed to make no difference...there was still visible light coming from the off leds in a row when the leds in the row above that were on.
But thinking on it more, perhaps you are still correct and I actually need the low side column driver to pull hard high when off, instead of just going to a high impedance state.
Such a frustrating problem, but I appreciate your reply and it may be several things going on here. I really need to get down and dirty with some scope time, but rather wait on the mixed signal scope and spend the meantime soldering up this other board with different low side drivers.
Thanks.
Edit: oh, I did see that you actually said pull the line *below* zero...haven't tried that yet.
-
Yeah I thought about push-pull too. I am surprised that didn't work either, and now I am curious to see what the new mixed mode scope shows you about this.
Pulling it down below zero just helps to discharge the led line harder for you. It might work, it's worth a try, and easy to setup on a test bench with an external power supply. The push-pull setup helps here.
-
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.
-
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....
-
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
-
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...
-
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.
-
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.
-
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 ;D
So three boards soldered with thousands of tiny connections, zero mistakes....at least I can do something right.
-
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 :P
Does this seem to make any sense?
Here is the schematic for reference:
-
Whats the refresh rate of the panel ??
Maybe slow it down a little, might get rid of some of the parasitic capacitance.
-
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.
-
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 :P
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
-
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.
-
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...
-
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.
-
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? :o
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? 8)
Along with the resistors, you may also need 72 diodes if my suspicions are correct! :P
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! ;D
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
-
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? :o
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! ;D
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". ;D
-
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.
-
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 ;D 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.
-
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.
-
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! ;D You gotta be lovin' it. 8) 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.
-
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).
-
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.
-
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
-
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.
-
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.
-
Could you give us an idea how you are using the matrix? I mean there are 432 LEDs to address and there is only 6 pfets on your board.
Chris
-
Could you give us an idea how you are using the matrix? I mean there are 432 LEDs to address and there is only 6 pfets on your board.
Chris
Sure. There are two banks of RGB LEDs, each bank with 6 rows and 12 columns (36 columns actually since each LED has 3 elements). The 36 columns are driven by three Allegro 16 channel low side drivers using only 12 of the 16 channels per chip. The 6 rows in each bank are driven on the high side by the 6 pfets, and the same pfets drive the 6 rows in the other bank (so pfet number 1 drives row 1 bank 1 and row 1 bank 2, pfet number 2 drives row 2 bank 1 and row 2 bank 2, etc.)
The 2nd bank also has three Allegro 16 channel chips driving the 36 columns.
What this all means is that at any single point in time, only 24 RGB LEDs can be on. There is no flicker because the banks are being switched at 540 hz (for a 90 frames per second update rate).
This method reduced the amount of Allegro chips needed from 36 chips down to 6 chips....but has caused me a world of pain in debugging this problem >:(
On a positive note (sort of), I did find that adding 6 10K pulldowns to the pfet drains and 72 10K pullups to the Allegro nfet drains totally eliminated the problem...all LEDs stay dark. But what a pain...78 more components...
-
Well there are resistor arrays of 16 resistors at once ...
-
On a positive note (sort of), I did find that adding 6 10K pulldowns to the pfet drains and 72 10K pullups to the Allegro nfet drains totally eliminated the problem...all LEDs stay dark. But what a pain...78 more components...
Occam's Razor - a simpler explanation is better than a more complex one.
I tried to prevent you from pulling most, if not all of your hair out chasing the problem. Lesson learned I hope, I had the same lesson too. In the digital realm, thou shalt use pull up/down resistors and never ever leave anything floating. One would figure that on the output of a fet that really isn't necessary, but its still digital, just at a higher voltage and/or current. And thanks to codeboy2k, I also know about the capacitances that are involved.
I just would like to say that is a very cool project, I like the PacMan demo in the YT video. I assume that once all the kinks are ironed out, these will be available forsale?
Chris
On edit:
On a positive note ( not sort of), you did solve the problem! Even though you have to re-spin the board and have the additional components to add, you ( along with help of the forum) trouble shot the problem and fixed it, instead of just covering it up with the plastic over it. Success is good!
-
Occam's Razor - a simpler explanation is better than a more complex one.
I tried to prevent you from pulling most, if not all of your hair out chasing the problem. Lesson learned I hope, I had the same lesson too. In the digital realm, thou shalt use pull up/down resistors and never ever leave anything floating. One would figure that on the output of a fet that really isn't necessary, but its still digital, just at a higher voltage and/or current. And thanks to codeboy2k, I also know about the capacitances that are involved.
I just would like to say that is a very cool project, I like the PacMan demo in the YT video. I assume that once all the kinks are ironed out, these will be available forsale?
Chris
Thanks Chris. The main reason I didn't jump straight to the pullup/pulldown solution is I wanted to research the problem and see if there were any easier solution (either in hardware or software). The resistors still feel like a "hack" and don't particularly make me happy, but I am at the point where I don't see an easier solution.
I will probably do a rev2 soon including pads for these resistors plus a few other changes. I would like to do a few hundred boards eventually such that I can justify pick and place and reduce component costs significantly due to volume. The board was designed for a particular application but I have tried to make it universal and modular. It uses some fairly high quality components like the 3 amp switching regulator, 16 mbit flash, 60V common mode 15K esd protected RS485 chip, etc. The goal would be to produce the boards for around $35 including pick and place costs and then have the ability to grab as many boards as you want, throw them together in any configuration, talk to them all via RS485, and make any type, any size RGB display at 90 frames per second. We might try kickstarter just to get the quantity high enough to make several hundred boards near that cost. Otherwise, it takes me about 8 hours to solder each board (more time now that I have to add all those pulldowns).