--led-panel-type=FM6126A doesn't work seem to work past 128 pixels with either --led-chain=3 or shifting pixels to the right (128x64 x 3 = 384x64)

[marcmerlin]

root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 --led-panel-type=FM6126A -D10
(--led-parallel=3 with active board) works. It seems that --led-panel-type=FM6126A works well enough to init all 3 boards

When I tried to use a single chain (for wiring simplicity), this also works fine: root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=384 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=1 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 -D10 --led-panel-type=FM6126A (--led-cols=384 --led-parallel=1) well, it works, but only because the panels were already initialized by the first command (it doesn't work after a fresh powerup)

Now if I do this root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=3 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=1 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 -D10 ( --led-cols=128 --led-chain=3) this still work, but I dropped --led-panel-type=FM6126A . If I leave it (next command) it actually breaks the 2nd and 3rd panels.

If I re-add --led-panel-type=FM6126A, then it send a new init that breaks panels 2 and 3. From there root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=384 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 -D10 --led-panel-type=FM6126A does not fix the problem either. I need to plug the panels back into 3 chains, re-init them, and then they're ok again

[marcmerlin]

Here what it looks like

[marcmerlin]

Other finding, after a fresh powerup: root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=384 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 -D10 --led-panel-type=FM6126A only inits the first panel. But if I re-run it, it then inits 16 columns of the 2nd panel, and then another 16, until all 128 are working (re-running the command many times). And once I get to the 3rd panel, it got initialized all at once.

[marcmerlin]

Semi relatedly, I'm not sure if 196x128 (64x128 x3) is reasonable to run with a single chain (which was my hope to have a single daisy chained cable for my wiring). root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=3 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=1 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=11 -D0 gives me 140Hz, which isn't terrible, but looks bad on pictures

root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=3 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=1 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=4 -D0 gives me 390Hz which is better, but at the expense of color depth

--led-slowdown-gpio=0 gives me a nicer 700Hz but the display is garbled enough that it's not usable. Is it reasonable to expect to run 192x128 (24576) pixels on a single channel with a reasonable refresh, or should I expect to have to use 3 ribbons?

[hzeller]

Can you check if the latest commit fixes it ? (i.e. that you can use --led-chain=3 --led-cols=128).

In general, try to rather use parallel connection than chained connection. The shift-register of the panels is only of limited speed, so there is a limit in clock-speed.

A panel with ABCDE adressing (1:32 panels with 64 rows) are in general pretty slow in refresh because the whole refresh cycle needs to go through 32 double-rows. If you find "outdoor panels", they typically have less address lines and thus are faster (then choose with --led-multiplexing the kind of multiplexing they do).

[marcmerlin]

Thanks @hzeller so, this half fixes it. I can now init the panels by simply doing root@rPi3:~# ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=3 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=1 --led-pwm-dither-bits=1 --led-pwm-lsb-nanoseconds=9 --led-pwm-bits=7 -D10 --led-panel-type=FM6126A when before your patch, this wouldn't work at all (but using 384 instead of 128, did)

But, I need to run the command 17 times, each time it inits 16 colums, and then the next 16, and then the next 16 until the first 2 panels are done. The 17th time inits the last panel all at once. Thanks for the tip on speed, I will look at getting A(B)C panels which you just started supporting in https://github.com/hzeller/rpi-rgb-led-matrix/issues/823 (thanks)

Is it ok to re-open this until the init sequence gets sent in such a way that all the panels get initialized all at once, not by sending the init 17 times?

[hzeller]

Can you dig at the code to see how to make this work in your set-up ? I don't have a FM6126A panel to test this myself, so the implementation is mostly based on hearsay :)

The relevant code is at https://github.com/hzeller/rpi-rgb-led-matrix/blob/master/lib/framebuffer.cc#L399

[marcmerlin]

yes, I'll have a stab when I can (I did bring the hardware to france to hack on it during Xmas)

[hzeller]

You find a lot of details in this thread: https://github.com/hzeller/rpi-rgb-led-matrix/issues/746

[marcmerlin]

Sorry, didn't have time to work on the FM6126A issue, all my Xmas hacking time ended up being spent on my project of a glue driver to compile and run arduino graphics code on rPi and render it on rPi with your RGBPanel driver. It's a bit of a hack, but it works :)

https://community.pixelmatix.com/t/preannounce-smartmatrix-gfx-and-fastled-neomatrix-on-top-of-rpi/579 Code: https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix + https://github.com/marcmerlin/FastLED_RPIRGBPanel_GFX

As discussed in the other bug, I'm not sure if AB or AC panels will be a lot faster than ABCDE, and if they're not, I'm going to be stuck using parallel connections to get a proper refresh rate, in which case, FM6126A init past 128 columns may not matter as much.

[marcmerlin]

Another update (sorry, not a fix), I just did a test with 3 // 4 in series, and the FM6126A sequence only went 3 panels deep. The 4th panel didn't get a full init sequence. I re-ran 6 times or so and eventually the init sequence went all the way through the 4th panels on all 3 chains. I ran this command: ~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=4 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-bits=7 --led-panel-type=FM6126A -D0

Interestingly with 3 panels deep and 3 parallel, the init sequence was sent reliably to all 3 panels each time.