I have a bunch of Cailiang 64x32 P4 Indoor panels. These panels work fine but have the odd setting they need to be set to 64 rows for a 32-row panel. Got all working except the output is distorted whatever I select in the settings. Tried different panel type chipsets, the chips used in these panels are the FM6125 but these are not available as driver.
I’m using a 3-channel board with 3 chains of 2 panels each, making it a 128x96 pixels display. Tested on a Raspberry Pi Zero 2W, also tested on a Raspberry Pi 4 2GB with the same results. If the panel is set to the physical number of rows and columns, only the bottom half of the LEDs are shown with the upper half of the chain, shifted 16 rows downwards.
Left most photo
sudo ./led-image-viewer /home/pi/images/VO8W_Panel.gif --led-cols=64 --led-rows=32 --led-chain=2 --led-parallel=3 --led-multiplexing=0 --led-row-addr-type=0 --led-brightness=50 --led-no-hardware-pulse
When selecting 64 rows instead of 32 rows, each chain is displayed correctly, but the lower row is shifted to the middle row chain (which is another channel).
middle photo
sudo ./led-image-viewer /home/pi/images/VO8W_Panel.gif --led-cols=64 --led-rows=64 --led-chain=2 --led-parallel=3 --led-multiplexing=0 --led-row-addr-type=0 --led-brightness=50 --led-no-hardware-pulse
When setting the chain length to 4 panels (i.e. double the real number of panels per row), dots get doubled in size, but all panels are used.
right most photo
sudo ./led-image-viewer /home/pi/images/VO8W_Panel.gif --led-cols=64 --led-rows=32 --led-chain=4 --led-parallel=3 --led-multiplexing=0 --led-row-addr-type=0 --led-brightness=50 --led-no-hardware-pulse
Changing the --led-multiplexing and/or --led-row-addr-type only results in one to 8 rows shown in garbled lines or checkered order distorting the image.
I’ve tested these panels with an ESP32 with this library https://github.com/mrcodetastic/ESP32-HUB75-MatrixPanel-DMA and things work fine when using the E-selector wire/pin and set the number of rows to 64. Also working correctly with a larger chain up to 6 panels. But I have to set the panel rows to 64 to work properly.
Anyone experienced this or knows whats wrong in my settings? Any help, hints or tips are appreciated.
Hi, if your panels need to be treated like 64x64 panels with an E-line, you likely need to do some soldering on the board, which is what I had to do to get my 64x64 panels to work: P4 needs to be connected to GND, and E needs to be connected to P8 (see the readme). If you have the electrodragon V1 board, I insert two before/after images below showing how I did it with jumper heads. It should be similar on the V2 boards. HTH!
Hi Bertolt,
Thanks for your reply. I have a RPi HAT controller board that is identical to the schematic design of @hzeller ( rpi-rgb-led-matrix/adapter/active-3/schematic.pdf at master · hzeller/rpi-rgb-led-matrix. And already set pin 4 to GND and pin 8 to E since I’ve discovered this was necessary on the ESP32 to get the board working. It seems that this board uses a 1/64 scan ratio instead of a 1/32 scan ratio. There are only 12 FM6125 chips on a PCB to control 64x32 LEDs, as where most 128x64 boards have double the amount of driver chips.
Shoot, ok, then that is not the issue. Sure you have tried this, but what happens when you use --led-multiplexing=1 instead of 0 in the settings for the left most photo? If that does not help I am at a loss unfortunately. Maybe order some more standard 64x64 panels instead and build the project with those?
If you are certain the board has a 1/64 refresh rate, something I have never heard of, I’m sure you understand this means you need 6 address lines (ABCDEF), not 5.
I don’t think this is your issue though because the extra lines would never light up with any of the options you picked, and you do get them to light up.
you clearly have another set of weird panels with unusual addressing.
my recommendation is find whatever library options you need to light up all the pixels and then you’ll have to fudge the library pixel mapping to put the pixels back on the correct place on the panels.
I did some analysis and it seems this type of display has only half the number of driver chips, so the scan is doubled by using the E-line to select the other half of the 32 rows (which clarifies only half of the panel displaying when using a 1/16 scan). I’m trying to get the exact connections from the multiplexer chip to the drivers. Also seems that the driver chips are FM6124’s (most of the prints are removed but on one panel they forgot one) and not FM6125 as the webshop stated. Meanwhile trying to setup a ESP32 to control the panel using a pixel-by-pixel approach to confirm my assumptions.
Update: When setting the number of rows to 32, the E-line is not used. This causes only the first half (16 pixels = 1 driver) of each row/chain is displayed. When setting the number of rows to 64, the E-line is used and the first and second half of each panel is used.
I’ve tried any combination of --led-multiplexing=<0…17> and --led-row-addr-type=<0…4>, but none of these has a postive result.
How can I set command line options or mapper to use the E-line for 32 rows (i.e. 2x 16 rows)?
Please show the photo of the panel rear side
Picture of the back plane. Marked the IC’s, other IC’s are FM6124 chips. E-pin enabled on connector. Mind the 32S in the boards model number. A board from the same manufacturer but P5 size, has double the chips and has 16S in it’s name. This might indicate the scan rate.
Hi
Your panel virtually is a half of 64x64 32s panel. You can easily use it with almost any library if you setup it as 64x64 and will draw on higher part only.
Yeah, that’s what I experienced in the first place. See my first post, middle picture. It’s working fine on an ESP32, although limited on the number of panels due to sufficient computing power, and on a Teensy 4.1. Both using the same library to drive the panels, and the library is able to choose a 1/32 scan rate. With the rpi-rgb-led-matrix I am unable to change the scan rate to 1/32 using the E-select line for a 64x32 panel.
Indeed. But you can use the scan rate 1/32 with 64x64 panel. So setup your panel as 64 pixels high.
PS
The common problem for most HUB75 libraries (as for rpi-rgb-led-matrix, as well for maptastic ESP32 library) - they not used a scan rate as independent panel parameter… so you need to find a workaround in case of non-trivial panel structure.
When setting the number of rows to 64, you get what you see in the middle photo in post #1. All odd rows are okay, but all even panel rows are missing, they’re not even send to the panels. So it looks like the frame buffer is read wrong. Makes sense since the panel driver will start the next panel at row 64. So somewhere there’s an offset in the driver that needs to be halved in the frame buffer after each panel row.
