I’m not seeing those issues with my P12 panel, and ESP32_FORUM_PINOUT with long wires and no buffers:
It could be an issue with that panel, or could be improved by adding buffers
Same result with another panel (very different model using THT LEDs)
What exactly do you mean by buffers? Are those to be implemented in software or hardware? I couldn’t find mentions of such buffer examples on the GitHub homepage or Wiki of the project.
Also, what are you doing with all the grounds of the HUB12 connector? Did you connect all of them to the board’s ground or just one? What about the unused D and E ports, are they connected to ground or just floating?
Maybe it’s a wiring problem on my side after all. Thanks!
I didn’t connect up C as you don’t need that line for a /4 panel. C,D,E are left floating. I connected one GND pin.
From the wiki:
Some panels won’t work with the 3.3V levels output by the ESP32, and you’ll need 5V level shifting buffers like the SmartLED Shield designs use. Additionally, the shields have some other features that make them preferable to using just an ESP32 (and optionally level shifting buffers):
Take a look at the THT board design and BOM in the /extras/hardware/ESP32 folder for parts and a circuit.
You were righ regarding the C pin. It’s the same without it.
Strange. Now we have the same wiring and I’m still encountering the glitchy LEDs. I will try getting my hands on a level shift to try in the next days, but I doubt the 3.3v is a problem or that the matrix itself is defective. (isn’t the Raspberry Pi GPIO 3.3v too? This exact matrix runs without artifacts connected to a pi and controlled with hzeller’s rpi-rgb-led-matrix library.
Anyway, I’ll keep digging and update here if I somehow solve it.
Just to eliminate some potential hiccup, what sketch are you writing the Hello world with? Is it using Adafruit GFX or not? Could you share the code so that we run the exact same thing on the seemingly same hardware/wiring please?
It’s Adafruit_GFX with two lines changed:
const uint8_t kPanelType = SMARTMATRIX_HUB12_16ROW_32COL_MOD4SCAN; // Choose the configuration that matches your panels. See more details in MatrixCommonHub75.h and the docs: https://github.com/pixelmatix/SmartMatrix/wiki
const uint32_t kMatrixOptions = (SMARTMATRIX_OPTIONS_HUB12_MODE); // see docs for options: https://github.com/pixelmatix/SmartMatrix/wiki
I agree with you if it’s working with a 3.3V RPi, then there’s likely no difference with level shifters.
Have you tried swapping wires? Sometimes those cheap jumper wires are faulty. You can also try swapping the pin numbers in case one of the pins on the ESP32 is bad.
What are the settings you’re using with the rpi-rgb-led-matrix library?
Sorry for the late reply but I had to consult with my colleagues that ran this panel under rpi-rgb-led-matrix. It seems like the basic settings are pretty standard (16 rows, 32 cols and led-inverse enabled I think), but the most involved part was using a custom pixel mapper that looks like this:
void MapSinglePanel(int x, int y, int *matrix_x, int *matrix_y) const {
if (y / 4 == 0) {
*matrix_y = y % 4;
if (x / 8 == 0) {
*matrix_x = x + 24;
} else if (x / 8 == 1) {
*matrix_x = x + 48;
} else if (x / 8 == 2) {
*matrix_x = x + 72;
} else if (x / 8 == 3) {
*matrix_x = x + 96;
}
} else if (y / 4 == 1) {
*matrix_y = y % 4;
if (x / 8 == 0) {
*matrix_x = x + 16;
} else if (x / 8 == 1) {
*matrix_x = x + 40;
} else if (x / 8 == 2) {
*matrix_x = x + 64;
} else if (x / 8 == 3) {
*matrix_x = x + 88;
}
} else if (y / 4 == 2) {
*matrix_y = y % 4;
if (x / 8 == 0) {
*matrix_x = x + 8;
} else if (x / 8 == 1) {
*matrix_x = x + 32;
} else if (x / 8 == 2) {
*matrix_x = x + 56;
} else if (x / 8 == 3) {
*matrix_x = x + 80;
}
} else if (y / 4 == 3) {
*matrix_y = y % 4;
if (x / 8 == 0) {
*matrix_x = x;
} else if (x / 8 == 1) {
*matrix_x = x + 24;
} else if (x / 8 == 2) {
*matrix_x = x + 48;
} else if (x / 8 == 3) {
*matrix_x = x + 72;
}
}
}
It is a custom implementation taken from this GitHub issue of the rpi-rgb-led-matrix project, as usually, like the name implies, this library doesn’t drive single-color panels - Meta bug: Support HUB08/HUB12 · Issue #531 · hzeller/rpi-rgb-led-matrix · GitHub
But it works perfectly. Do you know of any way to port this kind of mapper into pixelmatix?
P.S.: regarding wiring and boards, multiple combinations were tried. Plus, the same ESP32 drives a HUB75 RGB without issues.
Take a look at the MultiRowRefreshMapping example sketch, and try it on your panel.
This is the mapping for the HUB12 panels I have:
At a glance the mapping looks the same as the one you posted.
SMARTMATRIX_OPTIONS_HUB12_MODE already inverts the data line, which I’m guessing is the same as “led-inverse enabled”
Have a nice day. I’m also trying to get the HUB12 display up and running. I have it connected to ESP32 directly in the mod forum. And the result looks like this. The first pixel is in a different location. Can you help me. Rene
I haven’t seen that behavior before. Can you please post a longer video where MultiRowRefreshMapping runs through all the pixels and starts repeating so I can see the full mapping?
I took a full video of mine doing the MultiRowRefreshMapping (it actually needed some modifications, to use the mono layer and display „only full red”, which for my panel is white, in order for the dots to show up). I think it’s the similar to the behavior illustrated above.
@BodoMinea and @renda71 can you share where you purchased your panels? I may want to get samples to test. Also can you show photos of the back of your panels just in case that’s useful?
Hi, I have 3 variants of displays at home. Versions 1 and 2 of the outer version 3 are the inner inverted. They all work well with the DMD3 library. The mapping you have right just is the wrong timing. I will try to put pullup or down resistors on the outputs for edge banding. The DMD3 library is slow and ESP32 with a web server is not enough to refresh the display. That’s why I want to use the smartmatrix library. You have an inverted implementation in your library for use in version 3. I bought the displays on aliexpress and ebay over the course of two years.
Otherwise, I’m glad you’re developing this library. I will support you.
Hi René, thanks for your donation which motivated me to dig out my HUB75 panels and bare ESP32 to connect up the panels and see what’s going on. I was able to reproduce some of the issues here, and found a fix:
const uint32_t kMatrixOptions = (SMARTMATRIX_OPTIONS_HUB12_MODE | SMARTMATRIX_OPTIONS_ESP32_INVERT_CLK);
It looks like sometimes the clock needs to be inverted. I’m not sure if that’s the case on all hardware setups, but it helped with the panels I have here and a bare ESP32.
For your version 3, it looks like you don’t need the inversion on the data line. You can do a quick fix for now, just comment out the code that inverts R1. There’s two places in the code with inversion:
Hope that helps, LMK if you’re still seeing issues.
Hi,
I have also tried using this:
And it changed this:
to this:
And also with that additional config it shows some kind of flicker, but not much in terms of different LEDs being lit up.
I assume that the other piece of advice with the editing of the files is just for the inverted panel and wouldn’t help in my case. So what you see is the result of just adding that to the config.
Thanks.
@BodoMinea I think you have a different issue with your panel. I can’t reproduce it here. If you can get me a sample of your panel (I’m in the UK) or let me know where you got it, I can try to reproduce the issue.
(I didn’t see your other post update when I posted this, maybe you’ve gotten it to work now?)
Nope, that’s another type of panel. HUB75 and RGB. There are two separate topics for the two types I am testing. For those I found the control voltage to be the issue and my level shifts to not be working. Will investigate the shifters you pointed me to, otherwise the issue is software-wise closed as the library is driving them as intended.
But the panels we´re talking about here are HUB12, monochrome and 3v3 friendly (tested with rpi-rgb-led-matrix on Pi 1, 3 and 4, directly connected) but light up the wrong pixels - as seen in the above pictures/videos.
I currently cannot obtain the information regarding their sourcing (I didn’t buy those myself) and also cannot send you one because I am not at my office until later next week. When I get back there I will do that and also test multiple panels I have (I think I also have some red ones with the same arrangement, or at least some red ones that are tested with rpi-rgb-led-matrix as working), test all hardware combinations and if I don’t uncover anything I’ll ask for your details in order to have one delivered to you.
@BodoMinea you might want to lower the clock speed to see if that helps:
Apologies if I already suggested this or you already tried this, I have limited time to help out with these things and can’t keep all the details in my head.
Hi, thank you for your reply. The patch does not work on any version of the display. Also version 3 after pixel negation behaves the same. It is not visible without negation. I also reduced ESP32_I2S_CLOCK_SPEED - nothing. Can I invert a font written with USE_ADAFRUIT_GFX_LAYERS? So I don’t know what to do next.