--led-slowdown-gpio=5 not enough on Pi 4 with long chain

[ntwallace]

Hi @hzeller, first off thank you for creating this excellent library. The documentation is fantastic and has been very useful to get started.

I'm having an issue running a long-ish chain of 32x64 P5 panels from a Pi 4 + active-3 hat where --led-slowdown-gpio=5 produces tearing in the final panels. Running a chain of 12 panels from a single output, I get ~500Hz refresh with the final 4 panels showing bad artifacts:

IMG_8506.mp4

If I modify led-matrix.cc line 621 to allow for gpio_slowdown > 6 and then run the demo with --led-slowdown-gpio=6 it resolves the tearing issues in all panels, however I'm then limited to ~60Hz:

IMG_8507.mp4

Given that slowdown =5 runs fine for the first 8 panels at 500Hz I assume there's some middle ground to be found here? I haven't had a chance to dig into the library further to see how you're implementing gpio_slowdown in the runtime options struct, but is there something you recommend testing next? Limiting the refresh rate using --led-limit-refresh=x while running --led-slowdown-gpio=5 doesn't change anything, even if I drop it down to 60Hz.

Thanks!

[raymondmars]

@ntwallace Thank you very much! I meet the same problem, modify led-matrix.cc line 621 to allow for gpio_slowdown > 6. It works for me.

[marcmerlin]

I don't have this configuration, but I'm a bit surprised that having longer chains would require a longer delay between pixel data. I thought the signal wouldn't degrade since it is regenerated by the output of each panel. Do you think the timing shifts due to some drift in those chips?
Either way, if it fixes it, it's a useful workaround. I'd send @hzeller a pull request to allow a bigger value on that option, there is no harm in allowing bigger numbers if they help

[ntwallace]

@marcmerlin It's strange, but I definitely think it could be an issue with timing shifts — similar to what is seen on APA102s over long chains at high speeds. Setting the value to 6 I'm able to run 36 P5 panels (384x192) from a Pi 4 with active hat with minimal artifacts, but the refresh rate isn't amazing (150-200Hz with pwm bits set to 3).

Are you familiar at all with the way @hzeller is handling slowdown in gpio.cc? I haven't had a chance to play around with it much, but I wonder if changing the set/clearBits functions to use specific timing vs looping would help. I'll submit a PR for the large slowdown value when I have a second.

[hzeller]

I suspect the clock gets unaligned. Internally, the led matrix shifts stuff into a shift register and passes the output to the next shift register. Of course, the output is always slightly delayed.
Now if the panel does not also delay the clock signal it passes on to the next panel, the data edge and clock edge will get closer and closer with each panel (as shift registers slightly delay, but clock is passed to all simultaniously) this might result in the observed problesm.

I suspect adding a delay between each panel (e.g. two inverters in sequence on the clock line between panels) could mitigate that.

wrt. GPIO slowdown implementation: it just repeats the output multiple times so that the overall clock speed is slower. The reason why it is repeating instead of attempting some timing is that it all goes through the GPIO bus which slows down things a lot. Though I am open to improvements in that, as this is still from the very early version of rpi-rgb-led-matrix 10 years ago when there was at most a slowdown of 1 needed for long chains with slow panels on a Raspberry Pi 1...

[marcmerlin]

Ah, yes, the clock gets out of sync over time as more chips are regenerating the signal code with a small delay each time, that makes sense. Thanks @hzeller
@ntwallace, a workaround more than a fix, but parallel channels will fix this by making shorter runs and will also increase your framerate

[ntwallace]

@hzeller thanks for jumping in here. That makes sense to me and I believe something similar happens with clocked addressable APA102/SK9822 LEDs in long runs. I'll pickup some inverters next time I place a mouser order and get out the scope to see what's going on. I figured that code hadn't changed much over the years, I'll do some testing next week when I have free time.

@marcmerlin I'm actually running the 36 panels as 3x12 parallel channels at the moment. I suspect running 36 on a single chain wouldn't be possible given this issue.