P5 8S SM16208 panels do not work

[GeorgeFlorian]

I am encountering difficulties on HRL-P5-8S-LED1922-64x32-v2.0/P5-SMD-8S-3 that use SM16208 chips and have ABC pins.
I am using the Active-3 board.

Colors are okay, but the matrix mapping is all over the place and it changes for each --led-multiplexing option from 0 to 20.

What is even weirder is that the HUB75 pins are ABC and NC, and you'd think that --led-row-addr-type=3 should be the correct option, but when setting it to 3 it does not work as intended.

Based on:

--led-row-addr-type=<0..4>: 0 = default; 1 = AB-addressed panels; 2 = direct row select; 3 = ABC-addressed panels; 4 = ABC Shift + DE direct (Default: 0).

Playing demo 4 (which lights up the whole screen) or a simple code that colors the whole screen works with --led-row-addr-type=0 but when setting it to 3 only some rows light up, not the whole thing.

Where do I even start creating a new multiplex map ?

[board707]

What is even weirder is that the HUB75 pins are ABC and NC, and you'd think that --led-row-addr-type=3 should be the correct option

Hi
Which addressing option to use, can be easily set by the chip type on the matrix.
Please indicate the part numbers all chip on the panel other than main driver SM16208

[GeorgeFlorian]

What is even weirder is that the HUB75 pins are ABC and NC, and you'd think that --led-row-addr-type=3 should be the correct option

Hi
Which addressing option to use, can be easily set by the chip type on the matrix.
Please indicate the part numbers all chip on the panel other than main driver SM16208

The black casing says P5-SMD-8S-3
The board says: HRL-P5-8S-LED1922-64x32-v2.0

There is also a code: 03N049P2E4293A2
The black chips have something like SM6208SJ written on GU,RU and BU.

On the U1 I can make up the last letters being 245B, but the first ones can be M1, MI, N1, NI. I can't really see and I don't own a microscope

[board707]

Could you show a photo a whole panel ( rear side) ?

[vasi26ro]

I have tried this panel with the LedArt app and Huidu D16 without success

[marcmerlin]

so, I'm going to give you an honest answer, there seems to be a near infinite amount of incompatible panels, and no one is being paid to write addressing code for them, so unless you add support or personally find someone to add support for them, it's not going to happen since Henner doesn't spend his days adding support for panels he doesn't have himself, has never seen, and has no personal need for :)
If you look into the source code in the addressing/multiplexing code, you can probably figure out to add new panel types, but that's about it.
For what it's worth, normal ABC panels work with addressing=3, I have 2 batches that are 4 years apart and they both work.

[board707]

If the issue is just the addressing code, then such a panel cannot be called "incompatible". Almost any type of addressing can be figured out in a few tests even without having a panel in hand.

Incompatible panels - are panels with new types of drivers, such as s-PWM drivers or drivers with a built-in buffer. Adding support for each such driver is a job that will take many weeks or even months.

[marcmerlin]

@board707 we can argue on semantics, but the point remains. Unsupported panels will remain unsupported until someone provides code to support them. If there is an expectation that this will come from Henner, I know him personally have talked with him recently, and he has plenty of other things to do.
That said, you seem to know what's going on, so please feel free to step in and provide pull requests, those will get looked at.

[board707]

That said, you seem to know what's going on, so please feel free to step in and provide pull requests

To do that, I need to get a Raspberry Pi board in my hands :) Up to now, I used HUB75 screens with low memory controllers only - STM32, RP2040 etc.
I am planning to test your library with Pi Zero.

[marcmerlin]

get a Pi0 2W, it's cheap and almost as capable as a rPi3. I just benchmarked it last week:
https://rpi-rgb-led-matrix.discourse.group/t/rpi0-2w-speed-compared-to-rpi3a/913/2

[board707]

Thanks for the link, I just registered there.

[GeorgeFlorian]

Oh my God, this got a lot of traction and attention.

I understand that it's impossible to get every panel working, I just hopped to get some pointers as to what I can try to get this one working. The supplier that I get my panels from only has these ones now, which I cannot make work.

It is obviously an addressing issue. I have tried every possible combination of settings and none outputted a correct image.

Unfortunately, I am not that good of a programmer to figure out the addressing.
I am even willing to pay somebody to help me with these panels as these are the only ones I can get my hand on right now.

[ScobbyDoo]

Same issue with me , I've made simple solution.

I've managed to get same lot of led module which is supported by setting i tried.

Instead of Re Mapping leds & put efforts on this kind of solution, batter to switch on supported modules , it's helpful for other library too.

[vasi26ro]

@GeorgeFlorian I am working with a similar panel here in Romania, I have send you a friend request in linkedin, maybe we can find a solution.

By now I have found a way to configure correctly the panel with a huidu hd d16 controller and I captured the signals with a logic analyzer.

I would try to replicate this signals from this library. Hopefully I can write the mapper.

With this command: sudo ./pixel-mover --led-row-addr-type=0 --led-multiplexing=19 --led-slowdown-gpio=2 --led-rows=32 --led-cols=64 the bottom half of the panel works. The first half is always white.

[board707]

@GeorgeFlorian , @vasi26ro , @ScobbyDoo
Colleges, figuring out a pixel mapping is not as difficult as it seems. I have developed a method that allows me to configure a pixel mapping for almost any panel, and for most panels I do not need to have it in hand - it is enough for you to run several tests and show the result on video.

The problem is that I do not work with the hzeller library. I have my own DMD_STM32 library and it is written for boards on the STM32 and RP2040 controllers. In issue #1686, one of the users already referred to my library as an example of working with complex pixel mapping.

For those who think it is possible to use other controllers - I suggest testing your panels on my library. In the future, I plan to try to add some mapping options to this library, but this will take time, since I have never worked before with Raspberry boards

[ScobbyDoo]

So , it means whatever buffer any library is generating,
Pass that buffer to remapping function & cast pointer at same position but just circular buffer.

It means same buffer will rearrange, with any other same size static buffer , basically its just lookup table which works as in pair of 2 4 8 or 16 bytes & skipping positions.

So what portion of your library's snippet will help to remap any led module in that case? I think chatgpt helps for quick implementation

[board707]

I'm not sure I understood exactly what you mean.
The general principles of pixel mapping are the same, but the specific implementation depends on the library. I am not using a circular buffer.

what portion of your library's snippet will help to remap any led module

What I wrote does not mean that I already have code for any matrix, I only developed the principles of writing it for a specific panel. The main code for working with pixel mapping in my library is located in the file
https://github.com/board707/DMD_STM32/blob/dev-V2/DMD_Panel_Templates.h

The method of figuring out of the mapping is described in another library discussion -
mrcodetastic/ESP32-HUB75-MatrixPanel-DMA#622

[vasi26ro]

I have tried the following command sudo ./pixel-mover --led-row-addr-type=0 --led-slowdown-gpio=2 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat --led-multiplexing=19 --led-brightness=100 --led-limit-refresh=100 -t 10

This looks almost perfect, but there is some ghosting going on. If you can point me where in code to look maybe I can find a solution faster.

I am using this code: master...briggsm:rpi-rgb-led-matrix:p5outdoor8s64x32MultiplexMapper

IMG_5318.1.MOV

[board707]

This looks almost perfect,

Huh?
What was supposed to be shown on the screen?

To test the mapper I would recommend to run a code that fulfill a panel pixel by pixel from upper left to lower right corner.

[vasi26ro]

In the video, i am using pixel-mover from the examples-api-use/ dir.
This example allows you to move a pixel around the screen from (0,0) top left, anywhere on the screen. Also the argument -t 10 adds another 10 pixels as tail to the leading pixel.

By moving this pixel, I can see that the mapping is correct, but there is some ghosting and flickering. If it helps, I can get capture a part of the signals from the hub75. I also have a capture with the working signals from the huidu led controller.

[vasi26ro]

The setup that I have:

• rpi 4b
• Adafruit RTC HAT
• The hat is in quality mode with GPIO18 soldered to GPIO4

Here is the rotating square from: sudo ./demo -D0 --led-row-addr-type=0 --led-slowdown-gpio=2 --led-rows=32 --led-cols=64 --led-gpio-mapping=adafruit-hat --led-multiplexing=19 --led-brightness=100 --led-limit-refresh=100

IMG_5319.1.MOV

[board707]

Sorry, this video show nothing for me about mapping.

Could you run something this:

 canvas->Fill(0, 0, 0);
 for (int y =0; y < canvas->height(); y++) {
   for (int x =0; x < canvas->width(); x++) {
    canvas->SetPixel(x, y, 255, 0, 0);
    usleep(30 * 1000L); // wait a little to slow down things.
  }
  }

and show on the video about 10-15 seconds ?

[vasi26ro]

IMG_5321.2.1.mov

If is too fast I will make the video again

[board707]

Thanks
Looks like a problem with the row switch.
Remind me what panel you have (dimensions, scans) and what driver chips are installed on it.

[vasi26ro]

The panel is the same one as @GeorgeFlorian HRL-P5-8S-LED1922-64x32-V2.0 with SM16208SJ MW245B, others I do not have noted and I am away from the panels until Sunday or Monday.

[board707]

@vasi26ro
Could you show a photo a whole panel ( rear side) ?

@GeorgeFlorian - the same question for you

[vasi26ro]

This is the best image that I have.

[board707]

Thanks.
I asked the photo to look up a muliplexor chips. Know a type of multiplexor is a critical thing to work with LED panel.

It seems that multiplexors there are below the plastic bars of the frame:

if you can't somehow make out what's written on them, we will have to assume that this is a standard line driver type, so your set an option --led-row-addr-type=0was correct.
In this case, the cause of the ghostings on your picture should be sought in a bad connection. These panels are very critical to the quality of the contacts, especially to the connection of GND.

[board707]

@GeorgeFlorian , @vasi26ro , @ScobbyDoo
Lets continue our conversation about pixel mapping.
Now I received a Pi Zero. I just tested hzeller's library in real hardware and successfully tried to figure out a pixel mapping on few my panels.

If the problem of choosing correct mapping for your panels is still actual, we could try to solve it together. All that is required from you is to run several tests with the code that I will send and show the result on video.

@vasi26ro
Last time I made a mistake testing your matrix, so I decided that it has problems with the driver. Maybe it's not that bad :)

[marcmerlin]

@board707 figuring out the mapping is not exactly hard, and those panels may be zag zig which is already known as a mapping.
The missing work is to write an alternate mapper in the code. Are you offering to write one in a way that it's reasonable to merge in the main codebase?

[vasi26ro]

@board707
Thank you, can you tell me what tests to run?

[marcmerlin]

@board707 Thank you, can you tell me what tests to run?

you can simply displays dots one by one and see where they end up, but as I wrote, the mapping is likely already known, what's missing is for you or him or someone to write the actual code for the mapping.
Until someone volunteers to do that, not much will happen.

[board707]

Are you offering to write one in a way that it's reasonable to merge in the main codebase?

Yes, that's exactly what i'm going to do.
After i got used to the library, i wrote mappers for two of my panels yesterday.

[board707]

can you tell me what tests to run?

please run this code again:

canvas->Fill(0, 0, 0);
 for (int y =0; y < canvas->height(); y++) {
   for (int x =0; x < canvas->width(); x++) {
    canvas->SetPixel(x, y, 255, 0, 0);
    usleep(30 * 1000L); // wait a little to slow down things.
  }
  }

but now with settings --led-rows=16 --led-cols=128.
Do not set any special mapper.

PS It is just a test, not a solution yet.