Help with 128x64 FM6124D Panel (1/32 Scan) - Dead rows / incorrect mapping

[markusmuc]

Hello everyone,

I’m working on a project with a 128x64 P2.5 LED panel and I’m struggling to get it working correctly with the rpi-rgb-led-matrix library. After many systematic tests, I’m hoping someone here might have experience with this specific type of panel.

My Hardware:

• Raspberry Pi: Pi Zero 2 WH with a fresh 64-bit RaspiOS Bookworm Lite (2025-05-13-raspios-bookworm-arm64-lite.img).

• Controller: Electrodragon RGB Matrix Panel Drive Board (Model: MPC1119-3 (202504)), which uses the “regular” GPIO mapping.

• Power Supply: Mean Well MW RSP-200-5.

• Panel: A 128x64 pixel panel with the following details:

  • IC Driver Chip: FM6124D

  • Panel Model (on PCB): P2.5-2121-HL 2.0

  • Connector: HUB75E

  • Scan Rate (from a spec sheet): 1/32 Scan
    (I can provide photos of the back of the panel confirming the FM6124D chip if needed.)

---

The Problem:
When I run the library demos, only half of the rows are active. Specifically, it seems that rows 1-16 and 33-48 (0-indexed) are completely dead, while rows 17-32 and 49-64 display content. This creates large black bars and a “split” image.

This is the output of the grid test (demo -D 8), which clearly shows these dead zones:

---

The command used for the grid test above was:
sudo ./demo -D 8 --led-rows=64 --led-cols=128 --led-chain=1 --led-gpio-mapping=regular --led-panel-type=FM6126A --led-slowdown-gpio=2 --led-rgb-sequence=RGB

What I’ve Tried So Far (Troubleshooting Summary):

I have systematically worked through all the common solutions, but none have been able to activate the dead rows.

1. System Setup: I started with a fresh install, disabled the onboard audio (dtparam=audio=off), and successfully compiled the library. The base command runs without crashing.

2. Parameter Testing:

• I have tested all relevant combinations of --led-row-addr-type (0-4) and --led-multiplexing (0-8).

• None of these parameter combinations fixed the dead rows. Most of them made the image worse (e.g., completely scrambled). This strongly suggests the issue is not a simple mapping/scan-pattern problem that can be fixed with parameters.

3. Code Modification (Attempted Init Fix):

• Based on research for the FM6124D chip, a specific initialization sequence (sending the command 0x0030) is often required.

• I modified the lib/framebuffer.cc file to “hijack” the InitFM6126 function and send this 0x0030 command instead.

• I can confirm via a printf statement in the code that my modified function was successfully called .

• Result: This code modification had no visible effect on the dead rows. The problem remained exactly the same.

My Conclusion:
The issue seems to be a fundamental incompatibility. The panel requires a specific initialization sequence to enable all its address decoders (especially for the 1/32 scan, using the ‘E’ line), and the 0x0030 command alone is not sufficient for this specific panel model.

My Question to the Community:

Has anyone successfully used a panel with this specific combination of FM6124D driver , 128x64 resolution , and 1/32 scan rate ? Is there a known, more complex initialization sequence or a different RowAddressSetter required that I’m missing?

Any help or insight would be greatly appreciated. I’ve hit a wall after exhausting all the standard troubleshooting steps.

Thank you for your time

[markusmuc]

Hi everyone,

A quick and very important update. I received a response from the panel supplier with some fantastic technical details.

They confirmed it is a 1/32 scan panel and requires the HUB75E interface. They specifically pointed out that the E-signal (on Pin 8) is not being used correctly in my current setup.

Here is their technical explanation for the initialization:

---

Based on their suggestion of Row Address Type=5, I reverted all code to its original state and tested the parameter. Unfortunately, it did not solve the issue; the dead rows remained.

This leads me to a new hypothesis, and this is where I would truly appreciate your expertise. Since the software parameter alone didn’t work, I suspect the issue is a physical connection on the Electrodragon controller board .

My core question is:
For my specific board (MPC1119-3 (202504)), do I need to add a solder bridge to physically connect the E-line signal? I have seen references to connecting a pad labeled “P8” to one labeled “E-BUF” on some versions of these boards.

MPC1119 DAT

Could someone with experience with these newer Electrodragon boards confirm if this hardware modification is the missing step to make the E-line functional?

Thank you all for your help

[board707]

@markusmuc

Has anyone successfully used a panel with this specific combination of FM6124D driver , 128x64 resolution , and 1/32 scan rate ?

The combination of 128x64 size and 1/32 scan is perfectly standard and has nothing specific in it.
The only detail that you missed in your description - what the model of line switching driver chips installed on the panel.
The clear photo of the panel rear side also could be useful.

[markusmuc]

I have finally solved the mystery, and I want to share the solution for anyone who might face this problem in the future.

After all the software tests, parameter combinations, and even code modifications failed to activate the dead rows on my panel, the final clue was a nagging suspicion about the physical hardware.

The Problem Was a Missing Physical Connection on the Controller Board.

My specific Electrodragon board (Model: MPC1119-3) , while modern, does not automatically connect the E-Line signal from the Raspberry Pi to the HUB75E connector. This signal is absolutely essential for 1/32 scan panels like mine (128x64) to address all 64 rows. Without it, the panel behaves as if half of its rows don’t exist, which is exactly the problem I was seeing.

The Solution: Manually Connecting the E-Line on the Controller

I had to create a physical bridge on the Electrodragon board. I found two pads/pins on the PCB:

• One for the E-Line output to the HUB75 connector (labeled P8 ).

• One for the E-Line input from the Raspberry Pi’s GPIO (labeled E_BUF ).

MPC1119 DAT

By creating a simple jumper connection between these two points, the E-Line signal was finally passed through to the panel.

After making this hardware modification, the panel now works PERFECTLY with the following, standard command:

sudo ./demo -D 0 --led-rows=64 --led-cols=128 --led-gpio-mapping=regular --led-slowdown-gpio=2 --led-rgb-sequence=RGB

No special --led-panel-type, --led-row-addr-type, or --led-multiplexing parameters are needed! The standard library driver works flawlessly once the hardware is correctly connected.

---

Thank you to everyone who read along. It turns out that after this long monologue and debugging journey, the solution wasn’t a complex software patch, but a tiny piece of wire. Sometimes, you just have to connect the dots… literally!

I hope this helps save someone else a lot of time.

Best regards,
Markus

[board707]

My congratulations.

@markusmuc

This signal is absolutely essential for 1/32 scan panels like mine (128x64) to address all 64 rows.

By the fact it is not always true Some panels can controlled by only three address pins - ABC and still be able to address any number of rows. Moreover, it is the only way to address a panels with scan more than 1/32.
For this type of addressing a new option of --led-row-addr-type=5 was recently added to the library.

[jonms]

This sounds like the manufacturing problem I spotted.
If it is then do contact electrodragon and they’ll send a replacement!

They said they were contacting everyone who purchased a faulty board.

New electrodragon board version with E line problem?

I ordered some electrodragon boards and they are marked as V 2-2. They look different to the pictures elsewhere and appear to have a problem with the E line. My existing setup works fine with the adafruit bonnet, so I know the matrix boards are good. With the electrodragon boards I get the ‘missing band’ you’d expect without the E line. After trying every conceivable option combination with the test/demos I put a logic analyser on the output and found there’s no E line signal on pin 4 or 8, …