PHimmel
commented
4 years ago Update:
Apparently the constraints for --led-slowdown-gpio are relatively arbitrary and can be adjusted in led-matrix.cc, here: https://github.com/hzeller/rpi-rgb-led-matrix/blob/1ca622655a8573fffd646d2ea24fb2fdc85d70ae/lib/led-matrix.cc#L626-L631 (After making the adjustment be sure to recompile, aka re-'make', the git clone)
Using a slowdown value of 6 has pretty much taken care of the aforementioned issue! (There still is a bit of vertical ghosting present when on a black background).
If the upper-limit of the cap is arbitrary, and won't cause any detrimental effects, then why not raise it higher than 5? I'd imagine this would be a relatively common problem, although I haven't seen much mention of it in Issues.
Hello Mr. Zeller (as well others who are kind enough to offer their input here). Thank you so much for your contribution with this software, as well as for actively maintaining it and resolving issues posted here.
I have had success using a RPi 3 B+ for running 12 64x64 panels flawlessly. After a hapless short circuit involving its GPIOs, I obtained a RPi 4 B 2GB. I had anticipated it would outperform the 3 but so far have hit a wall.
My current configuration arguments are: --led-rows=64 --led-cols=192 --led-parallel=3 --led-pixel-mapper=V-mapper I have tried a multitude of other combinations as well - all ultimately resulting with the same issue. I have the --led-slowdown-gpio set all the way to 5. (I notice that when I put it on 4, the almost identical issue emerges on the following panel in the chain[is the RPi 4 really just too fast?])
Any panel more than 2 results in the same error in the photo. The issue manifests within a consist period of time (generally every ~2 seconds), and always involves the lower 32 rows and the rightmost 16 columns --- which extend to the top.
It is also exacerbated by brightness (increased brightness == increased faulty display).
I'm also getting a bit of ghosting as well when I have the ./clock running on a black background.
I have checked my wiring repeatedly as well as fully rewired multiple times too. I got a fresh microsd card and tried Raspian Lite, DietPi and regular Raspian - all with the same issue.
I tried every additional flag and received some success with --led-pwm-lsb-nanoseconds=~50 as well as with --led-pwm-bits (works best with ./clock). Interestingly, --led-no-pulse-hardware helps a bit as well. The best so far is --led-pwm-dither-bits=1, it signficiantly limits the visual disturbances for ./demo. . . It's just that the issue is still present and it feels as though these adjustments are only masking the underlying root cause of the problem. - Also, using those modifications greatly increases CPU usage(I suppose it is artificially slowing it down, which in-and-of itself adds to the CPU load?). I also reserved the 4th core for refreshing, as you recommend.
I'm using a 5V80A SMPS. It is outputting ~5.07V and at the inlet it is around ~5.03V. I added only one 4700 µf capacitor so far, to a test panel to see what affect it had on the issue - none.
This is the level-shifting circuit that I made. I actually rebuild/rewired it in hopes that it would clear up the problem. I followed your basic format in the active-shifting board (save the nice interfaces and exact ordering of the lines).
My total setup ended up working superbly (after some mild tweaking) and I was learning the library to create my own programs and never expected this to occur upon the simple change of one pi to another (faster) one.
Thank you again Mr. Zeller, I have spent many hours learning and working with the programs that you have made and following the instructions that you created. It has been a challenging, fulfilling experience that has resulted in a beautiful display.
And thank you to any others that are knowledgable and can offer assistance.