FPP 10.0 - When LED Panel Type = ICND1065L, Panel Addressing Type acts like Standard with ABC selected

[dalerayee-hub]

NOTE: IF YOU DO NOT ATTACH YOUR LOG FILES, THEN THERE IS A HIGHER PROBABILITY THE ISSUE WON'T BE RESOLVED. (Steps at end)

Please answer the following:

FPP Version and Hardware:
Example: FPP 4.2 running on BBB
FPP 10.0, running on Pocket Scroller+ V3.0.0 8 output, Beagle Bone

Describe the bug and Steps to reproduce:
A clear and concise description of what the bug is and the steps to be taken to reproduce.
In Web UI Output Select
Panel Type Selected = ICND1065L
Panel Addressing Type: ABC-Addressed Panels
Panel Layout: W=1 H=1
Panel Size : 128x64 1/32 Scan

No LEDs light when, Testing = Panel Layout (or any setting)

Connecting Logic Analyzer to ABCDE pins shows the ABC pins are walking a standard pattern for a 3 of 8 decoder. This is not expected for ABC-Addressed Panels Setting.
If Panel type is changed to Standard, and set the Addressing Type to ABC, then the ABC pins show on the logic analyzer as a pattern when A=Row Clk and C=Din to walk a single 1 thru the Row shift register.
With Panel Type set to ICND1065L, the Addressing Type selection appears to have no effect and ABC pins always look like 3 of 8 pattern.

Expected behavior:
A clear and concise description of what you expected to happen and why.

Expected to see the Panel Layout Pattern on the LED Panel
Expected to See the ABC pins toggling where A=Clk, C=Din to Row Addressing Scan Shift register part.

Additional context:
Add any other context about the problem here.
Panel is a 128x64 panel based on ICND1065L and RUL5258 chips. (shift register row control)
Addressing is wired where A=Row Clk, B=Blanking, C=DIn, D and E are grounded.

Additional Attachments
Please include the log files. To create the file:

1. Open the FPP UI
2. Open the the File Manager (Content Setup->File Manager),
3. Select the "Logs" tab
4. Click "zip" button.
5. Attach to this ticket.

If applicable, add screenshots to help explain your problem.

FPP-East_Logs_20260912_2305.zip

[dkulp]

I just pushed a commit to master that hopefully addresses this. That said, I don't have any of these panels so I'm more or less guessing. If you could flip to master and give it a try, that would be great.

[dalerayee-hub]

Thanks for the update. The A and C pins look closer to expected. The B pin is now toggling the same as A which I don't think is correct for this RUL5258 part. I will try disconnecting B so it is always low and see if that helps.

[dkulp]

I pushed another fix that should hold b low.

[dalerayee-hub]

Thanks for the update. The Row logic appears to be ok now, and the waveform towards the LEDs look reasonable. However I still have no LEDs being turned on. Now beginning to look closely at the ICND1065L. The HUB75 pins are connected to the 1065L as: CLK -> DCLK, LAT -> LE, OE -> ROW I assume this aligns with the FPP expectations.

[dkulp]

Thanks for sticking with this, and for the analyzer captures — they've been what made each step diagnosable.

Good news on the row addressing: your report that the row logic and the data waveform now look right means that part is done, so please don't spend more time there. What's left is the driver chip's configuration, and you were right to suspect it.

Why the default was never going to work for your panel. FPP ships one captured register profile per PWM chip. Ours for the ICND1065L was captured from a 1/48 panel; yours is 1/32, and until now all FPP did was patch the scan-count register and use the rest as-is. That's not close enough — comparing against a public capture catalog, every 1/32 ICND1065L profile differs from our built-in one in several registers beyond the scan count (0x07, 0x1d and 0x23 all move). The profile that actually works depends on the panel's row driver IC and pixel pitch, not just the chip and scan rate, which is something FPP can't guess. So we've made it something you can supply instead.

Two new things are on master (not in 10.0 — you'll need to switch to the master branch to get them):

1. Import a register profile

The catalog of captures lives here — right-click → Save As:

https://raw.githubusercontent.com/kingdo9/rpi-rgb-led-matrix_pwm_experiment/master/lib/spwm/registertest/data/icnd1065l.profiles

Then on the LED Panels tab, with LED Panel Type set to ICND1065L, you'll see a new PWM Register Profile row. Click Import…, load that file, and the dropdown fills with the profiles it contains — the ones captured at 1/32 are grouped first, labelled by row driver and pitch. Pick one, Apply Selected, then Save.

The file is read in your browser and never uploaded; only the chosen values go into your config.

Try these first, in this order. Your panel uses a RUL5258; the catalog has no 5258 entry, so the nearest neighbours are the sensible starting points:

1. icnd1065l_regtype318 — P2.5 - ICND1065L - RUL5158 - 1/32 — closest part number, right pitch, right scan
2. icnd1065l_regtype277 — RUC7258D - 1/32
3. icnd1065l_regtype316 — DP32020 - 1/32
4. icnd1065l_regtype22 — DP32019B - 1/32
5. icnd1065l_regtype45 — 7258 - 1/32

If none of those light it, there are 44 profiles at 1/32 in total — the dropdown lists them all, and working down the group is worth doing.

2. Sweep the OE pulse width

Also new, in a PWM OE Timing row on the same page. These panels advance one display row per pulse on the OE line, and a chip that doesn't see a pulse it likes simply never lights. FPP previously hard-coded 600ns with no way to change it.

The fields are in DCLK periods, matching the units the reference implementation for these chips uses (its defaults are 4 for the pulse and 12 for the opener). Leave them blank to keep FPP's existing timing.

Start by trying OE pulse = 4, then widen: 6, 8, 12, 20. Widening the pulse is the usual next move on a chip that won't light.

Combining the two

These are independent, and that matters: a profile that does nothing at the default pulse width may still work at a wider one. So rather than treating a profile sweep as conclusive, it's worth running your top few profiles at two or three pulse widths. If something lights at all — even wrong colours, wrong brightness or flickering — that's a big result, so please say so rather than discarding it.

One thing that would help a lot

If your supplier can send the NovaStar .rcfgx receiving-card file for this panel, please attach it. We checked: those files don't contain the register values (nor do ColorLight .rcvbp or Linsn .RCG — the receiving card keeps its own table per chip, the same way FPP does). But the .rcfgx XML does carry the chip code, the row-addressing table and GclkNumPerScan, which converts directly into the row timing FPP needs. That would let us stop guessing at the timing side.

When you report back

Useful either way:

• which profile and which OE pulse width you tried
• whether anything lit at all, even badly
• the fppd log — it now logs the imported profile name, word count, and the OE pulse/opener/row-period values actually sent to the hardware
• an analyzer capture of OE against DCLK if you still get nothing

[dalerayee-hub]

A quick update. No luck yet on getting any LEDs to light. I have tried all the entries listed in your last note and several OE settings on each one.
One thing I did notice is that DCLK and OE are not synchronous. See the attached short video.
In the video D15 = DCLK, D14 = LAT, D13 = OE, D8 = A (Row Clk)
Shouldn't the Row Clk and DCLK also be synchronous?
I will request the NovaStar.rcfgx file from the vendor, it will probably be Monday before he replies.

VID_20260919_215210475.mp4

[dalerayee-hub]

I received the file .rcfgx file from the vendor. Hopefully this provides the missing clues.
I added a .txt suffix so the file could be posted.

P2.5W 12864 JC-5L-5158_JJ.rcfgx.txt

[dalerayee-hub]

I noticed you made more updates, so I updated, so far no luck. I tried the suggested profiles and several OE values, no luck.
I see the Row Driver outputs driving to Vcc for 20uSec, which makes sense.
However the Column outputs from the 1065L never appear to enable -- the pattern doesn't change no matter what test pattern is selected, on or off. The output voltage sort of floats at mid-scale, picture attached. (This is a 3v3 panel)
I see there are new PWM OE parameters available, but not sure how to adjust those to be helpful.
What information can I provide to be helpful?

[dkulp]

At this point, I really don't think there is much more we can do. Someone will need to get the panels working properly with a color light card and do a logic analyzer capture of the output to be able to diagnose what we are doing differently.

[dalerayee-hub]

Ok, what model Color Light card do I need to acquire, based on the file I got from the vendor? Do I also need to buy a different controller, or can it be driven from the Pocket Scroller? Thanks, Dale.

…

On Tue, Sep 22, 2026 at 3:50 PM Daniel Kulp ***@***.***> wrote: *dkulp* left a comment (FalconChristmas/fpp#2955) <#2955 (comment)> At this point, I really don't think there is much more we can do. Someone will need to get the panels working properly with a color light card and do a logic analyzer capture of the output to be able to diagnose what we are doing differently. — Reply to this email directly, view it on GitHub <#2955?email_source=notifications&email_token=CN5GE76ZQVKBLXTD7K2CEYL5QLQZPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZYGM4TIMJSGUY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5783941251>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CN5GE73UNRDLR4JZSOZ2ZMD5QLQZPAVCNFSNUABEKJSXA33TNF2G64TZHMYTCNBTGY4TQNR3JFZXG5LFHM2TIMZXHE4TINRYGKQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CN5GE75XMMPHGBF5BG57MC35QLQZPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZYGM4TIMJSGUY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CN5GE7ZS2XPO3JW4W7HTFWT5QLQZPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZYGM4TIMJSGUY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>