1
\$\begingroup\$

I have been working at driving some of those generic LED matrix panels found all over the web for sale (such as this one), 64x32

I've struggled a lot with the lack of real documentation, but I've managed to create a pretty decent image using an FPGA and binary code modulation. However, I've got a problem with vertical ghosting that I can't seem to fix.

enter image description here

In the image above, all of the dim pixels within the circled area are supposed to be off, but as you can see the ones in the first row are not. Because these LEDs are half off, they don't ghost into the 2nd row.

If I turn the LEDs in row 16 off, the half-lit LEDs on the top row turn off completely, suggesting that the 16th row was "bleeding" over into the first (row 16 being the last row in the top half). In the image below, notice how row 16 (circled) is itself dimly lit despite being written to zero:

enter image description here

I didn't want to post my verilog code in full as I was worried it'd make the post too long, but I'll happily provide it if it helps. Regardless, the basic process I'm following to draw each top/bottom row pair is:

  • Clock out a row of data using RGB and CLOCK signals on panels
  • Blank display by taking OE high
  • Latch out the row data by taking LATCH/STB high
  • Take LATCH low
  • If we're on the final (5th) BCM iteration, increment current row (row address pins A,B,C,D) to set up for the next pair of rows
  • Take OE low to enable display again
  • Delay up to a value required for the current iteration of BCM output
  • Double the delay value for the next pass and repeat until the row has been output 5 times (5bit BCM, 15bit colour)

I'd be really happy if somebody could enlighten me as to exactly what causes the ghosting in the first place, and how I might go about reducing/eliminating it.

I've tried slowing the process down, moving the row/address increment timing so that it occurs slightly earlier and before, but nothing seems to help.

\$\endgroup\$
  • 1
    \$\begingroup\$ You need to be sure there is a 'dead time' when all LED's are OFF so you can change patterns without bleed over. Also treat these as RF projects in that ground returns need to be heavy copper braid if possible. Ground bounce can also cause 'echo' images. Each row or column should have its own ground return or power return to a common point at the driver board. \$\endgroup\$ – Sparky256 Sep 25 '18 at 23:40
  • \$\begingroup\$ The red pixels look clean, too bad there isn't a datasheet \$\endgroup\$ – sstobbe Sep 26 '18 at 0:53
2
\$\begingroup\$

All diodes and switches have capacitance when open circuit or biased with no current. This gives rise to slow decay time after switching commutation.

This bleed or ghosting thus has an effective RC decay time, which depends on commutation rate, and diode capacitance (which also increases with power rating) and driver decay time.

Your choices are several but depend on implementation.

  • 1) add dead time or turn OFF all LEDs just before commutation to next string and increase dwell until the ghost disappears at the expense of average brightness
  • 2) clamp the bus to achieve 0 mA in the LEDs and discharge its internal capacitance and bypass the driver current to each bus signal. Faster but at additional HW expense
  • 3) reduce the commutation rate at the expense of the risk of peripheral motion flicker
  • 4) use push-pull drivers at the expense of more HW cost
  • 5) use passive bypass across the LED bus using up some 1% of the LED current but effectively reducing the LED off time when a short deadtime is added at the end.
  • 6) use fewer LEDs in the MUX to reduce the commutation rate without compromising flicker so it does not have to be 16 x the frame rate using two Muxes of 1 to 8 or 4x 1:4 MUXed LEDs at the expense of more hardware.

I would experiment with 5)... add 1K across one LED to see if Ghosting diminishes (>3mA absorbed) then more or less to see if that has any effect as a starting point.

Failing that ... Then tweak your binary code to do 1)

Beware that that 5mm LEDs have extremely small gold whisker wirebonds to make them almost invisible so the PEAK current rating is only 50% more than rated e.g. 30 mA vs 20mA so pumping more risks damage to wirebond or adds heat to the junction. WHo knows how they did it?

Your LEDs may vary slightly in ratings. But this is why old 80 column 11?-segment LED displays made by HP did not MUX them in 80 steps but were specially made RED LEDs withstand 8x the current with 1:8 digits per commutation as I recall from late 70's on HP9825s.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.