ghost pixels one row below

[DerMaulwurf]

I wanted to build a 2x2 panel display with four 64x64 pixel panels. To avoid display flicker, I need to use a fast library like this one.

Sadly, I experienced some issues with ghost pixels, even on a single panel.

What I noticed: A ghost pixel appears when a pixel is set to a brightness level of RGB888(192) or above at any color channel. This is true for each individual color channel: RGB888(193,0,0) = no ghost, RGB888(194,0,0) = ghost, RGB888(193,193,193) = no ghost, RGB888(194,194,194) = ghost. All ghost pixels have always the same brightness level of about 64. A ghost pixel appears in the same column, one row beneath the original pixel. BUT : the ghost pixel appear per display half (upper / lower). This means that a pixel in row 31 has a ghost pixel in row 0 (still same column) and a pixel in row 63 has a ghost pixel in row 32 (still same column).

What I already checked:

• The wiring is not the problem. I checked with the proposed wiring scheme as well as with my own scheme. The effect was the same.

• The power supply is more than sufficient.

• I checked with three different panels of the same type, but with different production dates and revision numbers.

• I checked other firmware (e.g., Github/VGottselig/ESP8266-RGB-Matrix-Panel). No ghost pixels with these (but to slow for a 2x2 panel setup).

• Changing the panel brightness with setPanelBrightness() didn't help.

• Playing around with ESP32_I2S_CLOCK_SPEED didn't help.

• drawPixel(), drawPixelRGB565(), drawPixelRGB888() all produce ghost pixel^.

• FastMode on/off didn't help.

I started to debug updateMatrixDMABuffer

• the function contains a LED Brightness Compensation
• brightness 193 converts to brightness 126 (0b0111 1110) = no ghost,
• brightness 194 converts to brightness 128 (0b1000 0000) = ghost
• Couldn't find anything suspicious in the code of updateMatrixDMABuffer(), but I haven't understood every detail yet.

Since I was stuck at this point I brought in the scope to tackle it from the other end. Test case:

• disabled LED Brightness Compensation to preserve binary color patterns for easier testing
• write a single red pixel at (0,0)

Hooked up the scope to the OE-line, the address line A and to the R1-line. The A-line toggles after 34 cycles of the EO-line color(0 - 127) generate patterns on the R1-line within the first 24 OE-cycles. During the last 10 OE-cycles the R1-Line stays low. No ghost color(128 to 255) generate visually very different patterns on the R1-line and extend over almost all 34 OE-cycles. This time the R1-line is busy during the last 10 OE-cycles and there is a ghost pixel.

The ghost pixels must be artefacts produced by the panel. They are not part of the transmitted data. The test-pixel is at an even row (0,0) and has a ghost pixel at an odd row (0,1). There is data on the R1-line while the A-line is low but when the A-Line is high there is no data transmitted.

I'm convinced that it's a timing problem, but I'm totally stuck now. Do you have any advice? Is there anything I can check or try?

[vortigont]

Hi @DerMaulwurf I've fixed a similar bug recently in 39addf0fdf1d, but it's a little bit different approach to the library configuration. You might wanna try dev branch (we need testers anyway) :) Pls, check plasma example to get the idea of library initialization.

[mrcodetastic]

@DerMaulwurf

Can you:

1. Try version 1.0.2 of the library
2. Try the latest version in the git (main branch)
3. Try the dev branch

Ghosting has only every appeared if the brightness >= width of panel. Setting brightness to slightly less than the width of the panel avoids ghosting I thought. i.e. 50-60. You won't notice any difference in brightness either.

[DerMaulwurf]

Hi @mrfaptastic, hi @vortigont,

I tried the dev branch and it works great! The ghost pixels are gone and I can’t see any artefacts at all. Since the fourth panel I ordered didn’t arrive yet, I couldn’t test a 2x2 panel setup. A 3 x 1 panel configuration worked like a charm. Rock solid picture, no flicker, no errors.

Thank you very much for the great work.

[vortigont]

Great! Thanks for the confirmation for dev branch. By the way @DerMaulwurf, what are the driver chips your panels based on? Just for the reference.

[DerMaulwurf]

Hi @vortigont,

The first Board (the oldest one) is labeled P3(2121)64x64-32S-M3 and it is populated with

• 8 ICND2012 LED display line driver chip. Found a data sheet mostly in Chinese.
• 24 ICND2038S 16-Channel Constant Current LED Driver. Datasheet in Chinese only
• 2 74HC245C octal bus transceiver
• 1 74HC04 Hex Inverter The second Board is labeled P3-64x64-32S-2012-18G-1.2 QD and it is populated with
• 8 RUC7258 LED Gate Driver.
• 24 ICND2038S
• 2 74HC245SE
• 1 74HC04D The third board is labeled P3-64x64-2012-20B-1.2 QD and it is populated with
• 8 RUC7258 LED Gate Driver. Found a data sheet mostly in Chinese.
• 24 ICN2037BP 16-Channel Constant Current LED Driver. Datasheet in Chinese only.
• 2 MW245B (= 74hc245)
• 1 74HC04 I’m still waiting for the fourth board to arrive.

[mrcodetastic]

Thank you very much for the great work.

I agree. Great work @vortigont with your contributions!

[tsctrl]

not sure if we referring to the same issue. i am having extra pixel normally at the end or at center of the panel. tested with 3 panel with different chip all the same issue. not sure what config to change. changing the refreshrate and brightness didnt help

[vortigont]

@tsctrl not sure if that is the same issue, looks different. Could you try to draw some simple lines to find the correlation if any? is that at some specific offset or random flickering maybe?

[mrcodetastic]

Hi @tsctrl

1. Can you try with version 1.0.2 of the library, the current main branch, and the dev branch. Do you still have the problem?
2. Can you provide a photo of the whole panel - what line is this issue on?
3. Post your code. Thanks.

[jurriaan]

I also have just received the P3-64x64-32S-2012-18G-1.2 QD. If there's anything specific I can test please let me know.

What I find interesting is on the HUB75 IN connector the PIN below G1 is labelled 'M' instead of 'GND'. On the out connector that pin is labeled 'GND'

[mrcodetastic]

Hi @jurriaan,

If you have a spare moment, please test out the dev branch that @vortigont has worked on and provide any feedback. Thank you. :-).

What I find interesting is on the HUB75 IN connector the PIN below G1 is labelled 'M' instead of 'GND'.

There's no boundaries to what the chinese manufacturers come up with. I guess a simple multimeter check will see if it's GND?

[jurriaan]

I tried the dev branch, unfortunately it has the same results as master where it is incorrectly displaying (text displays as 'boxes' as if it for every pixel also lights up some adjacent columns as well, and also for some levels of brightness it will skip every other row if you set all the pixels to a single color) Will share more details tomorrow and share some pictures of what's happening.

I do like what is happening with the dev branch though. Easier to configure the library this way :)

[mrcodetastic]

Can you upload a photo please?

[tsctrl]

@mrfaptastic , @vortigont basically this happens when i use any custom font that was generated inside adafruit gfx library. the text will have additional 1px ghosting at bottom of the text and also pixel light up as picture above at the center or end of the panel. i will try the 1.0.2 and dev and investigate further.

[tsctrl]

Hi @mrfaptastic @vortigont , i have updated using latest master changes. basically wit this two lines of code change and the issue was disappear. //uint16_t _y = color_depth_idx ? y_coord : y_coord -1; uint16_t _y = y_coord; //uint16_t _y = color_depth_idx ? matrix_frame_parallel_row : matrix_frame_parallel_row -1; uint16_t _y = matrix_frame_parallel_row;

i will use dev branch for future testing

[vortigont]

that's interesting. Could you please, also provide what are the driver chips installed on your panels? Seems that there could be different ways how is LAT/address signals are handled.

[jurriaan]

Using this piece of test code on a working FM6126A display and the broken RUC7258 based display on the dev branch:

  dma_display->fillScreenRGB888(10, 0, 0);
  dma_display->println("Test 1 2 3");
  dma_display->setTextColor(0xF800);
  dma_display->println("Test 1 2 3");
  dma_display->setTextColor(0x07E0);
  dma_display->println("Test 1 2 3");
  dma_display->setTextColor(0x001F);
  dma_display->println("Test 1 2 3");
  dma_display->setTextColor(0xF81F);
  dma_display->println("Test 1 2 3");

FM6126A:

RUC7258 (P3-64x64-32S-2012-18G-1.2 QD):

I guess a simple multimeter check will see if it's GND?

M is indeed connected to GND :)

[mrcodetastic]

Have you connected all the ground M/GND pins... to ground on the power supply?

Problem with all these chinese panels is none are the same and are of variable quality or electrical tolerances just to shave 1c off the build. This seems electrical more than anything to do with this library.

The fact you have the issue with two types of panels leads me to believe it's a wiring/ground issue.

[jurriaan]

I only have issues with the RUC7258 version, the other picture of the working FM6126A I just provided to show how it's supposed to look.

I've also connected the M pin to GND, and now the vertical red bands are gone, and there is an even red background, but the horizontal bands still look the same, also those weird 7/8 blue leds on the bottom row stay on

[vortigont]

@jurriaan pls try to draw a single vertical line at (0,0)-(0,63) and a single horizontal somewhere in the middle. I'll try to find specs for those RUC7258 and see what this is

[jurriaan]

  dma_display->drawLine(0,0,0,63, 0xFFFF);
  dma_display->drawLine(0,32,63,32, 0xFFFF);

results in:

[vortigont]

OK, I found specs Looks like it's a completely different beast, it doesn't use ABCDE line as 1:1 address lines, it's a 3-address 8-output chip with two ENH, ENL cascading lines. And seems that it's internal schematics is dirrefent to allow driving 64x64 panels. This won't work with this lib approach that uses 16-bit shifters chips with ABCDE lines as a plain 5-bit address lines.

[jurriaan]

Interesting, it does have the same HUB75E connector though with E lines as well, not sure how those are connected. Will have to do some more reverse engineering then. Thanks!

[vortigont]

It might be helpful to ground E pin for the start and try 64x32 mode, also set brightness level to 100% to eliminate OE line control masking.

[DerMaulwurf]

@jurriaan @vortigont It doesn't just depend on the chips. I've got a panel with RUC7258 chips than works fine. It's labeled P3-64x64-32S-2012-18G-1.2 QD Another panel with ICND2012 chips has all sorts of strange patterns. It is labeled P3.91-2121-64x64-16S-JCGCPCB

afaik: P3 / P3.91 is the pitch 2121 is the type of led (SMD2121) 64x64 is the number of leds 32S / 16S defines the scan rate

On a 64x64 panel with a scan rate of 1/32 there are two pixels written per clock cycle. One in the upper half and one in the lower half. There are 5 bits of address needed (A, B, C, D, E) and 2 x 3 bits color (r1, b1, g1, r2, b2, g2). On a 64x64 panel with a scan rate of 1/16 like my P3.91 have to be 4 pixel written per clock cycle. This would result in only 4 bit address but 4 x 3 bits of color. Or 2x3 bits of color and a second latch-line. Or whatever... Unfortunately the connector isn't labeled so I can't verify my theory.

Nice explanation on this topic: https://www.sparkfun.com/news/2650

[jurriaan]

GND-ing the E ping and only driving it in 64x32 gave the same results, but now some parts of the display stayed blank (which is expected in that mode of course).

But, still some progress by changing the clock speed from 10Mhz to 20Mhz (mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_20M;) I got this on my display:

Also tried 16 Mhz, but that didn't work out (it looks almost the same as 10Mhz, but the red background is striped instead of solid red:

[vortigont]

@DerMaulwurf for sure it all a question of cascading 8- or 16-bit shifters. HUB75 is always shifts two rows x 3 bits wide, no way to pump 4 pixels simultaneously. So 64x64 panels with 1/16 scan rate could only be organized as 128x32 with 65-128 pixels of each row wrapped around to create one more row one way or another. And in that way one of the address pins (E) works not just as address but also as OE for half of the rows and that makes it tricky to control. On the other hand such panels are able to "light" four virtual rows at a time :)

[vortigont]

This one is indeed a really nice explanation - https://www.sparkfun.com/news/2650 I think it would be nice to mention this link somewhere in read.me

[vortigont]

@jurriaan you might also try configure matrix as 128x32 and see if this would allow more stable image, It would torn apart between rows, but at leas you could check if the pins switching timing model is more suitable that way

[jurriaan]

Tried all kinds of combinations with 128x32, but that didn't produce anything usable. Most usable is using 64x64 with and I2S speed of 20Mhz, if I reduce the brightness a tiny bit there's no ghosting anymore, so the only issue that remains is the two lit rows on the top and bottom half of the screen (as you can see in the first image in my previous comment).

What can cause these issues? And why does increasing the I2S speed make the text visible?

[tsctrl]

Hi @vortigont not sure which chips to focus on but i will list both chips in the each board. Basically this all the new board 32x64 i could get ship direct from 8 different manufacturer/seller from china (just to try out). few of the board are fm6124 (expensive/pcb look old/dead pixel). Panel with CHIPONE are look very new. Basically all are the same behavior and same issue. All has the same label as P5(2121)-16S-6432-XX board: XX is BO and M5 but with different chip.

PANEL - VERTICAL CHIP (MANY) | HORIZONTAL CHIP (LESS) BO - FM6124 | TC7258HNJ BO - TC5020A | CHIPONE ICN2012 M5 - CHIPONE ICN2038 | TC7258HNJ M5 - TC5020A | TC7258GN BO - FM6124 | GM7258C BO - SM16106 | SM5166P

this all the chip combination that different from board to board. Not sure if this helps

Thank you!

BTW the SM16106 are problematic board show random some pixel and cant get clear display. No worries on that i will not but that one again..

[mrcodetastic]

Can we have video of the issues?

[vortigont]

if I reduce the brightness a tiny bit there's no ghosting anymore, so the only issue that remains is the two lit rows on the top and bottom half of the screen (as you can see in the first image in my previous comment).

So, you mean that for any brightness level other than 100% it works fine except two rows at the top? And for the brightness level at 100% it behaves bad?

What can cause these issues? And why does increasing the I2S speed make the text visible?

The only idea that comes to my mind regarding higher clock ratio is that either OE or LAT signals under this circumstances are switching so fast that it overcomes the other issue with addressing signals for D or E. It is hard to guess without having a panel to test and I can't find any timing diagrams for RUI chips on how to control LAT/OE pins in correlation with D and E addressing.

[jurriaan]

@vortigont yes, the two rows on top issue remains regardless of the brightness level.

On 100% brightness there's a tiny bit of ghosting (see the posted image, mostly noticable with the green 'Test 1 2 3' line.) The ghosting disappears when the brightness is reduced a bit.

[vortigont]

The ghosting disappears when the brightness is reduced a bit.

Reducing brightness results in OE pin being pulled earlier than end of the row transfer, seems that a normal control where OE is pulled one clock before end_of_row is not enough for those boards (or maybe at those clock speeds). You may play with it here https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/blob/dev/ESP32-HUB75-MatrixPanel-I2S-DMA.cpp#L715

[tsctrl]

when @vortigont said about "Seems that there could be different ways how is LAT/address signals are handled."

this potentially due to how my logic level converter was wired. i will check on that. but how actually the correct sequence the library was handling. my logic level pin was set to a,b,c,d, oe, b1,g1,r1,b2,g2,lat,clk sequence. is this ok?

[vortigont]

@tsctrl all signals are parallel, but it might require some specific timings/order for different chips. You might try latest dev with @mrfaptastic commit for longer OE blanking between raw transitions.

[vortigont]

I've added a new method MatrixPanel_I2S_DMA::setLatBlanking(uint8_t v) in the recent commit to dev. It controls the number of clocks output is disabled before/after LAT signal. Would appreciate if someone could test with panels affected. Value could be set between 1 (default) to 4.

[DaveDavenport]

FYI: I just tried a 2 panel setup that had some ghosting on the 2nd panel, switching to dev branch looked like it is fixed. (got another div/0 error, but will make separate bug is I cannot resolve it). thx for great work.

[mrcodetastic]

Good to hear @DaveDavenport. A big thanks to @vortigont for the fantastic work in the dev branch.