LED matrix ghosting

[latigid on]

Hello,

I'm driving the attached LED matrix (6*8, where the 8 6 is 4*red, 4*green) with two shift registers and both high- and low-side drivers, at fairly high current. Some of the LEDs are Superflux type, whereas one row is with normal LEDs. So there is an extra current-limiting resistor for the latter.

Without the shown "Baker Clamp" diodes the display is ghosted. Especially bad is the normal LED row, where the Superflux LEDs light up unintentionally. With the Schottky diodes this problem is mostly gone and the normal LEDs light up by themselves as intended. But when the upper Superflux goes on, the Superflux below is lit, albeit quite dimly.

Is there a fix for this behaviour (easy or otherwise?). The design is already laid-out on a PCB but I can change it if needed. My software guru is against blanking the registers between updates.

Some ideas:

• a faster transistor (BJT or FET); any suggestions in SOT-23? Currently I use the BC818
• tweak the current at the BJT bases
• a higher-Vf clamp diode to turn off the BJT earlier
• individual resistors for each LED. would rather not but it could be done on a new PCB

Any help or advice appreciated.

Best,
Andy

[lapm]

Have you measured that those driver transistors properly shut off? Also make sure when your changing patter you zero display first. Had ghost images in 7-segment led display before realized this.

[Rerouter]

Add pullups on your PNP's and pulldowns on your NPN, without them it will never change state very quickly, try starting with 4.7K, Also check your code procedure make sure you turn off all rows and all columns before beginning the next, e.g. insert a black frame,

[capt bullshot]

Without a short blanking period, this ghosting is normal. Reason is the rather slow turn-off time of the bipolar transistors driven to saturation. This is also why the shottkys help. The "correct" way to handle thes would be to introduce a short (~ 10us) period, maybe by using the OE pin of the shift registers (if they have one).

[Zero999]

Try adding a small capacitor across the base resistor. Start with 47pF and increase it towards 1nF.

[mikeselectricstuff]

Start by adding gaps in the timing, as that doesn't cost anything.
I'd probably use mosfets, if only to avoid the resistors ( cost of placing the resistors with typically exceed the difference in part cost), maybe SOT23-6 dual MOSFETs. Maybe PN complementry pairs to reduce BOM

[mikerj]

Add pullups on your PNP's and pulldowns on your NPN, without them it will never change state very quickly, try starting with 4.7K,

Provided the micro's I/Os are being switched between high and low states rather than being tri-stated, then this won't make much difference.

Also check your code procedure make sure you turn off all rows and all columns before beginning the next, e.g. insert a black frame,

  This is very important, a blanking period is needed to remove ghosting.

[latigid on]

Many thanks for the replies so far.

I have tried adding pullups/pulldowns (PCB had provision for the latter already). A speedup cap parallel to the base resistor didn't help. MOSFETs, could do, but these would still require bias resistors, correct?

I'm approaching this from a hardware perspective, as the software is quite mature and is managed by another person. I don't think he wants to change his "ecosystem." His comment is that blanking the outputs will decrease the brightness by half, and it's not so convenient to send "wasteful" zeroes; the shift register chain also performs other functions.

Here's some (crude) tinkering: the serial clock supplies a burst of pulses while feeding in (and out actually) serial data. The latch pulses come on either side of this pulse train. I've placed a weak pull down of 22k on the /OE pin. I then connected the serial clock via 560R (anything less than ~1k seems to work) + 4nF in series to the /OE pin. This crude RC delay tristates the low-side rows on each clock tick.

Any drawbacks to this? I wonder if it would be safer to buffer the clock through something as I think the extra capacitance on the clock line may cause issues further along.

Thanks again,

[Benta]

Just keep the Baker Schottkys, you say they work. Everything is fine, then.

[capt bullshot]

The blanking must occur around the state changes of the shift register outputs. It is related to the latch pulse, not the clock pulse (but clock pulses may appear by chance near enough to the latching to work, don't know your system).
So from HW side alone, you'd want to delay the latch pulse by some us, and blank the display around the latch pulse. If you route the OE pin to the controller, this could be a simple job for the SW guy, depends on the way things were done in the SW.
Blanking by shifting zeros into the registers is a bad idea, since this consumes a lot of time that reduces the brightness indeed, not necessarily by half, also depends on the way things were done in the SW.
In general it's a good idea to let the SW guy explain you how it is done, show him your problem (maybe point out increases component cost) and talk him into discovering the SW way is the better way to solve the problem. You may want to provide him the GPIO pin routed to the shift registers OE, that would be my choice to solve this issue.

[mikeselectricstuff]

I don't think he wants to change his "ecosystem." His comment is that blanking the outputs will decrease the brightness by half,

That doesn't make much sense - you only need a small gap, and it seems unlikely you'd be clocking a shift register so slowly that loading data for a short gap would be a signifcant percentage of the display cycle.
Sounds like your software person just can't be bothered to fix it, so you have to add cost to work around it.

[latigid on]

Thanks again for the insights. I understand a little where the software guy is: this project runs in parallel with an existing version, so to keep it simple the software changes should hopefully be equally so.

There are actually two latch pins: one for digital in and one for digital outs. If I route the D_OUT latch through a 470pF cap to /OE with about 10k equivalent resistance to 0V, this gets rid of the remaining ghosting. Yesterday I was using the D_IN latch, which occurs in the wrong place. Interestingly, a series diode after the cap causes all sorts of mayhem or doesn't work at all (depending on the resistor/cap values).

[Ian.M]

It sounds like the output latch pin is positive edge triggered and /OE is active low.   Probably all that's needed is a single gate inverter between the latch signal and /OE.  Odds are the software guy has set the transfer up to be SPI-like.  i.e. a /CS signal goes low, the data is clocked out then the /CS signal goes back high again transferring the data to the output pins.  Confirm that by scoping the data out latch signal and the data clock.   If the /CS low period is appropriate for blanking, then adding the single gate inverter to drive /OE will be a robust solution.

Otherwise if there's a spare I/O pin on the MCU, then adding a separate blanking signal to drive /OE would be fairly trivial.  If the other board version has the same pin free, it wont matter if the blanking control is added to its firmware, otherwise it will need conditional compilation or runtime board detection to only activate it if the multiplexed LED display is present.