Ghosting, extra line above text.

[mxdmedia]

I am currently trying to drive this panel: https://www.amazon.com/gp/product/B079JSKF21/, using a NodeMCU ESP-32S.

I've modified the latest (just grabbed from Github today) pattern_test and pixeltime files, with the following changes:

PxMATRIX display(64,32,P_LAT, P_OE,P_A,P_B,P_C,P_D,P_E);

and then

display.begin(16);

The test pattern appears to work properly, however I am getting ghost lines below the drawn line, as can be seen here: https://imgur.com/a/0Fresun

Additionally, when I run the pixeltime code, I get funny lines just above any text or blocks/icons. An example can be seen here (note both the lines above any columns with text in them, as well as the ghosted/lighter colors above and below illuminated pixels):

Any thoughts on how to start troubleshooting this?

[2dom]

Panel ground to display ground connected?

[mxdmedia]

I'm not entirely sure what you mean by "panel" and "display" in this instance.

The Ground pin on the VCC/GND connector on the panel's circuit board does have continuity with the GND pins on the HUB75 connectors, and I do have the ground pin on my EPS32 connected to a ground pin on the HUB75 connector, so everything should be grounded properly.

[2dom]

That's what I meant ... sorry. Can you post a photo of the back of your panel including the connector labeling?

[mxdmedia]

No worries. Attached are a couple photos. Unfortunately, this panel has no labeling for either of the HUB75 connectors, nor did it have any documentation. I did probe the two ground pins that can either be GND or D/E, and neither of them had continuity with ground, so I assumed they were active D/E, and connected them appropriately. Edit- not sure why the photos are upside down. Will try to fix them.

[2dom]

Ok .... if this is 1/16 scan you should not require an E signal. Could you modify the contructor to

PxMATRIX display(64,32,P_LAT, P_OE,P_A,P_B,P_C,P_D);

and remove the E wire?

[mxdmedia]

Made the change above, and removed the E wire, and unfortunately it made no difference at all.

[2dom]

OK ... it might just be perspective (in you picture) but could you double check the LAT and OE connection on the input connector?

[2dom]

OE should be bottom left...

[mxdmedia]

I think it is just the perspective. I've got OE (bottom left, green wire) going to P2 on the ESP32, and STB/LAT (2nd from bottom on right, white wire) going to P22

[2dom]

OK ... what about power supply? Do you have something that can deliver 2-3A and do you use fairly thick cables to the panel?

[2dom]

Another way you could explore is to set

display.setFastUpdate(true);

after

display.begin(16);

This will change the timing quite a bit ...

[mxdmedia]

Power should be good- 5v 8a supply, and I am using the power connector that came with the panel, which has pretty beefy wires.

setFastUpdate didn't seem to have any effect. I do have an ESP8266 board sitting here that I'll give a try next, and see if the problem persists across boards. Part of me is wondering if there is something faulty with the panel/driver board, as this was a pretty cheap panel.

[mxdmedia]

I think I'm getting there. I noticed that my ground wire was being pulled a bit (was too short), so I ran a longer wire, and all of the ghosting issues (the light lines on the pattern test, and light ghosted pixels on the Pixel Time text) went away.

However, I am still having an issue with text. It looks like every character is being printed twice- in its normal position, and then again shifted down one pixel. See the attached photo. What is interesting- I am using the master Pixel Time code, which fades in the text. The non-duplicated top-most pixels are fading in as expected. All of the duplicated (and thus 'over-written') pixels dont seem to fade in nearly as much (they start out brighter than the top-most pixels, so have less range to brighten).

[2dom]

Maybe I screwed up the sample code ... What about the bitmaps/animations?

[mxdmedia]

A bit off topic, but I found a little bug in the pixeltime.ino file in master- Your brightness loop is: for (uint8_t brightness=0; brightness<256; brightness++) which causes a buffer overflow when brightness is incremented to 256, and at least on my board this sets brightness to zero, so this loop keeps looping.

After fixing that, I got the RGB rectangles (and weather icons). Looking closely (see attached picture) the top row (which I believe should be blank) is red + blue. Then the first row of green pixels is green+red, and finally the first row of blue is blue + green. Are there supposed to be 5 or 6 rows of each color? I am seeing 6 red, 5 green, and 5 blue (with the top row of each being 2-colors illuminated).

Also, the weather icons are clearly doing the same thing as the text- doubling up with a 1px vertical shift.

[2dom]

Could you try rolling back to

https://github.com/2dom/PxMatrix/tree/f72b4ea2d98ac55b562facef174ae2c1d47baf04

... there were some pretty big changes lately that might cause this ...

[mxdmedia]

Didn't have any effect rolling back to f72b4e. I'm starting to wonder if this is a hardware issue on my end.

[mxdmedia]

@2dom - thank you very much for all of your help today.

I actually figured out what the issue was. Originally, my issue was the ground wire not making a good connection. During our troubleshooting, you suggested that I get rid of the "E" wire, and take it out of the code (which makes perfect sense).

As a last ditch effort, I figured I'd add back in the E wire, and add it back in to the PxMATRIX constructor, and low and behold, with the fixed ground wire, it works perfectly! So it appears that on some panels, even with a 1/16 scan, the E wire is still required. You might want to note this in your docs for future users of this and similar panels. Cheers!

[2dom]

No worries - glad to hear that it works now! I think mentioning ghosting in the trouble shooting section makes a lot of sense - will do.

Just out of curiosity ... could you pull E statically to GND or VCC and check if that works too? I am not doing anything with the pin programmatically (apart from initialization) so we would save an GPIO here...

[mxdmedia]

Pulling E to ground seems to work as well.

[2dom]

Excellent!