Scan Failure - Garbled LED matrix panel display output (ESP32 GPIO is 3.3v).

[advadv00]

I have tested with a 1/32 scan P2.5 64x64 panel with Line E, and H file MATRIX_HEIGHT modified for 64x64
but testing doesn't work.
It comes out as if it's scan rate failure.

Is there any way I can use it?

[mrcodetastic]

This library has been built and tested on 1/16 panels 64x32. Though other users have had success with a 64x64 panel: #9

So I'm not sure what the issue could be, hopefully not a regression. @csloz - perhaps you could test the latest library with your 64x64 panel for me? Keep the old copy of this library unless I have introduced some weird regression.

[mrcodetastic]

@advadv00 - Can you pst a link to the panel you bought? Can you try the earliest version of the library 1.0.2 and see if that makes any difference? Please triple check your cabling?

[advadv00]

I tried version 1.0.2 and succeeded!
current version not work...
thank you!!

[mrcodetastic]

Ok. Will you be able to help me try and figure out the problem with the new library? I will create a new version in the coming days/weeks of library for you to test if you can spare some time to test.

[advadv00]

I will be happy to help!

[mrcodetastic]

When you get a momment, can you do a basic test using this branch of the library: https://github.com/mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA/tree/advadv00

Don't worry if the colours don't look right - I just want to confirm or not if you see garbage.

[advadv00]

test result...
There is noise, just like the previous result.

[mrcodetastic]

Can you send me a link to the panel you bought?

[advadv00]

Sorry.. I didn’t buy these. I got things with bad pixels.
I have 3 kinds of modules.

I found two factors affecting image quality.

1. LED module Power Voltage : Optimal at around 4.7V; Noise occurred above 5V.
2. I2S_CLOCK_SPEED : Some modules had to set the ESP32_I2S_CLOCK_SPEED to 20000000UL

In this picture, the first module had no effect on clock speed.
Components from the first module are missing from the second and third modules.

In the last picture, ESP32_I2S_CLOCK_SPEED is 10000000UL, left module is first module.

[mrcodetastic]

Ok. This looks like electrical issue then? The reality is these panels are supposed to have a signal input voltage of 5volts, not 3.3 volts - so the fact the ESP32 3.3v GPIO output even works with most of these panels is a hack in itself.

• Attenuation of the signal in either the cables to the first panel from the ESP32, or between panels may be enough to reduce the signal voltage enough.
• Grounding of all panels to a common ground is absolutely critical as well.
• Adding caps to the VCC and GND of each panel is critical as well. Refer to this: Red flickering when two 64x32 panels are chained #39

The clock speed output from the ESP32 can go down to even 8,4,1mhz, so try that even and see what happens - although you will notice flicker.

The only other option pehaps is to use a logic level shifter between the ESP32 to the first input pins on the panel chain - but I wouldn't know what to do here though. A random google search produced this though: https://www.aliexpress.com/item/4001131536726.html

• LED module Power Voltage : Optimal at around 4.7V; Noise occurred above 5V.

Could be issues with the power supply? I think it's due to the signal voltage being insuffient. Perhaps some of these panels aren't so tolerant to 3.3 volts.

• I2S_CLOCK_SPEED : Some modules had to set the ESP32_I2S_CLOCK_SPEED to 20000000UL

Signal attenuation of 3.3v signal and/or different panel LED driver chips that can't handle a high frequency.

Components from the first module are missing from the second and third modules.

Missing capacitors should be replaced with equivalents.

[advadv00]

Thanks for making the point well.
Some vendors' modules are missing some capacitors from the start.
Next week I'll put new capacitors on the module, and will test level shifter too.
I will tell you the result.
Thank you very much!

I'm not used to github, do I have to close this issue?

[mrcodetastic]

No problems. I'll close this once you get things up and running.

Out of curiosity, where do you get these used panels from? I wouldn't be suprised if there's now starting to be a flood of these panels going to landfill with dead pixels etc. I wouldn't mind getting hands on a recycled one instead.

[vortigont]

Just my 5 cents to this - I was able to hook up two panels 64x64 ABCDE 1/32 scan with FM6126A shifters and it works just perfectly. Still digging the code on how to find out refresh rate for these setup but for my naked eye it looks pretty good. I have two more panels stashed, so will try 4x64x64 setup soon.

[mrcodetastic]

Thanks for the update! Let me know how you get on with four of the panels chained! Turn on serial debug in the library as you might run out of memory with the ESP32 before anything else for that pixel resolution.

[vortigont]

Hell, it works! It just works! :) Can't believe that single esp32 can drive 256x64, and I have to admit it looks pretty well! At least some of those simple demos I've tried. Will do more tests later, but I'm already thinking of buying more of those Chinese panels. :) 👍

mem stat for 256x64
  Totals:
    free 152772 allocated 160960 min_free 150496 largest_free_block 113792

[mrcodetastic]

😀 😀 😀 😀 😀 😀 😀 😀 That's brilliant!
I didn't think it would work that well - haven't had a chance to test with that many real panels yet.

Best of luck with the extra panels hahaha!

[vortigont]

@mrfaptastic Thanks! Well, Christmas coming... time to buy a present or two... just for yourself :))
OK, I've hit mem limit, but not with I2S buffer but with aurora's effects trying to snatch too much WxH arrays for it's data, haha... Looks like it's time to refactor it a little :)
Will keep you posted,
cheers!

[mrcodetastic]

Closed due to contribution #42. Thanks @vortigont

[Orel-A]

LED module Power Voltage : Optimal at around 4.7V; Noise occurred above 5V.

AMAZING~!!!!!!!!!!!! Thank you sir!!!! I've worked on a problem with horizontal noise happenning, worked on this for 2 days straight. Changed settings, wires, soldered numerous time. Power supply didn't seem a problem for me at first, I've used 5V 10A power supply, outputted 5.4V. Checked with a multimeter saw a very small ripple. But the thing is that when I played with the wires it seemed like it changed the noise but this was all a misconception!!, no capacitors were needed at all as the cabling was short and the hidden capacitor near the end of the barrel jack did the trick... I fell at the first problem at wiring though, I didn't hook the GND of HUB75 connector on the ESP32 at first since I thought the GND on the INPUT from the board should do the trick, when I didn't hook it, I got a very horrible noise. Just the all screen color command worked okay, after that when I fixed the GND and saw that the noise reduced a lot but still remained a bit, that started all the tragedy as I fell to the misconcetion that my wiring was at fault. But who knew the voltage was very important ?? Guys listen to this guy, he is wise!

[Orel-A]

An Update: I solved the problem for good with 3.3V to 5V circuit. Two SN74HCT245N chips were used.

[mrcodetastic]

Hi @Orel-A. Thank you for letting us know the permanent fix for this!

Do you have a schematic of how you connected the ESP32 -> SN74HCT245N's -> HUB75 at all, using this library?

[Orel-A]

Yes I do have a schematic, but while prototyping I've made some small changes.
Some tips:

• You need WEMOS LOLIN32 and not the LITE version since it doesn't have a 5V pin.
• If you don't make a PCB for it, and use a prototyping board make sure you use silicone wires as they are soft and can be bent easily. You will have hard time otherwise.
• There is a similar chip name SN74HC245N, don't use it. Use SN74HCT245N only.
• As you can see in the image I've used single side PCB, but it's bad. Pads can be torn easily and they tend to use pure copper which can be oxidated. Better use Double Side Prototype PCB.

And this is the old schematic which I didn't follow 100% as so:

I didn't wire the E pin since my matrix is 64x32 and it's directly tied to GND.
Unused pins on SN74HCT245N should be tied to GND.
DIR pin determines the direction. High - A to B. Low - B to A. This can also be hard wired.

[colonelwatch]

• There is a similar chip name SN74HC245N, don't use it. Use SN74HCT245N only.

Because the HC245 variety uses 3.8V to signal a logic high, but the HCT245 only uses 2.0V, right? I noticed that this Adafruit HUB75 driver also uses an AHCT245 between the 3.3V ATSAMD51J19 and the HUB75 connector. I also noticed that my panel happens to use an 74HC245C instead, and it spits out garbage when I chain two. A proper 3.3V to 5V logic level shifter might be pretty critical after all.

Since I'm stuck with the same problem over here, I'll try adding a ICs of the HCT245 variety into my next PCB design. Hell, maybe I'll try to swap the chip on the panel itself if it's pin-for-pin compatible.

EDIT: No luck so far, though it maybe be that I just didn't design or build my PCB right.

[witnessmenow]

I'm running into this issue at the moment too, I need to dig more into it.

Using a "5v" power supply (actually 5.2V if measured)

I have a panel here that if I use clkPhase = true I get an issue on the output:

Setting clkPhase = false fixes the issue:

So this made me think that this panel just needs clkPhase = false

BUT even with clkPhase = true, if I power it from USB-C (which goes through a reverse feedback protection diode, Matrix is only getting 4.8V or so) the panel works fine

And if I use a level shifter on the output to the matrix using clkPhase = true it works with the regular power supply

Unfortunately the people who have made my trinity board have come across a panel and power supply combo that just doesn't work with any config I've supplied (it's hard to test without having the issue here) so I think all future designs need the level shifters.

Need to do more digging into it. If people are interested in the level shifter I can share the gerbers for them once its finalized. Here is the current schematic:

[witnessmenow]

Does anyone else have this issue? I may have (or someone in my discord realistically) come across a software workaround for it

  int pins[] = {25,26,27,14,12,13,23,19,5,17,18,4,15,16}; // This is just all the GPIO pins I'm using with the matrix.
  for(int i = 0; i< sizeof(pins); i++){
    gpio_set_drive_capability((gpio_num_t)pins[i], (gpio_drive_cap_t)3);
  }

It sets the amount of current that the GPIO can output up to 40mA (default is level 2, which is 20mA)

Image without this change:

With the above code:

[mrcodetastic]

Ha! Funny you should mention this.... I've been digging through the espressif idf recently and stumbled across this as well the other day.

I've implemented this into the library, so give it a try. aae55e9

[witnessmenow]

Haha, Awesome! Will give it a test soon

[witnessmenow]

It doesn't seem to be working for me.

It seems that GPIO_DRIVE_CAP_MAX is not resolving because if I change your code to

gpio_set_drive_capability((gpio_num_t)gpio, (gpio_drive_cap_t)3);

it works as expected.

[mrcodetastic]

Bizzare, compiled and worked for me, but anyway, have changed it to a hard integer.

[witnessmenow]

Maybe I'm assuming too much by saying its not resolving, and I'm being too vague.

It compiled fine but the matrix didn't work correctly (looks about the same as not having that code). I tried to serial print the value but I think that file is a C file and Serial is a C++ object and I'm too dumb to know what to do about that :D

[mrcodetastic]

Nobody's dumb around here! Ah, so interestingly what you're saying, if that code is in the Arduino sketch - then it works and sets the GPIO power output... but what I've put in the library doesn't do anything and the panel problem still persists?

[mrcodetastic]

Either way, I've made another commit and simply copy-pasted your code. If that doesn't work, then perhaps I need to put it earlier in the iomux_set_signal or something.

[witnessmenow]

Apologies I really didn't make it clear.

Your code as was didn't improve the display for me

Changing your code with the above line (in the same place) made the display work the same as it did when I had my original snippet in my Arduino sketch

[mrcodetastic]

Ok. I have changed the code to be an exact copy-paste to your original suggestion.

If that doesn't work then it confirms I am going insane. ha

[colonelwatch]

You're using GPIO_DRIVE_CAP_MAX? I searched for this in the esp-idf. While it belongs to the same enum set, gpio_drive_cap_t, this line (https://github.com/espressif/esp-idf/blob/5f38b766a83d18f78167d1d0dd8c8427ea1a36cb/components/driver/rtc_io.c#L69) seems to suggest that it's not a proper setting. You need to use GPIO_DRIVE_CAP_3 (which equals 3) for the maximum current.

[mrcodetastic]

Closing. ced87c0

[witnessmenow]

Yeah looks good!

[witnessmenow]

Just to confirm I have tested the new code with a bench supply and have tested 3V to 5.6V (afraid to go higher) all working well