Connection: Direct wiring from Pi to panel (regular mapping), no active adapter.
The Problem:
The display is split into four identical 32x32 quadrants. It seems the same image data is being sent to all four quadrants simultaneously, creating a mirrored/duplicated output.
Here is a picture of the issue:
Result: The 4-quadrant split issue described above.
Adding --led-row-addr-type=2:
Result: This was a key finding. The output changed from being garbled to a series of horizontal lines. However, the quadrant split itself remained unchanged.
Combining with Pixel Mappers: I tried adding --led-pixel-mapper="U-mapper", --led-pixel-mapper="V-mapper", and Chainlink, both with and without --led-row-addr-type=2.
Result: Absolutely no change to the 4-quadrant split.
Other Options: I have also experimented with various --led-panel-type options (FM6126A, FM6127), --led-multiplexing values, and different --led-rows/--led-cols/--led-chain combinations, all with no success.
My Question:
Has anyone encountered a panel that behaves like this? I suspect this panel has a non-standard internal wiring that requires parallel data input. Is there any known configuration I might have missed, or is this a case where a hardware modification (like an active adapter) or a custom pixel mapper is the only solution?
As a follow-up, here are the other images I couldn’t embed in my original post due to the new user limit. These show the results from some of the other commands I tried.
1. Result with --led-row-addr-type=2
This is the result I mentioned when adding the --led-row-addr-type=2 flag. As you can see, it fixed the garbled display into a series of horizontal lines, but the 4-quadrant split itself remains unchanged.
I did try to read through the documentation first, but I apologize if I’m approaching this incorrectly, as this is my first time working with these panels.
Regarding the chips, most of them are painted black, which makes them extremely difficult to identify. After looking very closely, I can barely make out what looks like the string ICN2037BP? on the chips at locations GU2–7 and RU10–15. The other chips are completely blacked out and unreadable.
I did some research and saw on the DMD_STM32 Wiki’s “LED Drivers” page that the ICN2037 is listed as “tested.” This led me to believe it might work without special settings, but unfortunately, that hasn’t been the case.
I have uploaded a photo of the entire rear of the panel and a video of the display’s behavior to the Imgur link below. Please take a look. Imgur: The magic of the Internet
Based on this new information, what would you suggest I check next? Any guidance would be greatly appreciated.
Thanks for the photo, although the picture mostly shows the frame, not the panel itself
But at least we now know for sure that you have a 16s matrix (see the label on the image below).
The height-to-scan ratio is 64/16 = 4, which means that the panel most likely has a non-standard pixel mapping and it will need to be selected by trying different values of --led-multiplexing option.
To properly configure the library, you also need to know the driver and multiplexer types. You have determined the driver chip as ICN2037. The multiplexer type is still unknown, but judging by the video, it should be the most common “3-to-8” type.
Thus, the necessary options for your matrix will be:
--led-rows=64 --led-cols=64 --led-row-addr-type=0
and with that, try to test various values of --led-multiplexing=<0..17>
I have now completed both sets of tests, but unfortunately, the issue persists. I systematically tested all multiplexer values (--led-multiplexing from 0 to 17) for both --led-row-addr-type=0 and --led-row-addr-type=3.
I have documented the results for each complete test series in the links below:
The only thing that clearly seen from the images that the panel needs
--led-row-addr-type=0
rather than 3
Nothing unusual, the pictures just means that you have to develop a new multiplexing code for the panel. If you ready to make some tests, I would try to help you.
