Flickering issue on Raspberry Pi 3 B+ using Hub 75

[uros-skopus]

Hi, Thanks for both great project and community established here!

I have the flickering issue with Chinese P5 outdoor module 192x64 (64x32, 3 cols, 2 rows), 1:16, SM16207 LED. I am using Raspberry Pi 3 B+ and active HUB-75 (powered over rpi) to control displays. Each time I run some additional processing in parallel (gps data extraction, sending data over cellular network...) my displayed image is distorted with constant flickering. What's the potential reason(s) behind this and how can I fix this?

[hzeller]

Unfortunately, right now there is nothing really known how to fix this, as any program messing with the memory bus might interfere with the constant need to send feed the RGB-Matrix. In particular the USB bus seems to be creating issues. Just being logged in and watching the ouptut of top through an ssh-connection generates some small flicker. I've heard from successful experiments using corepi as operating system which reduced flicker somewhat.

(also, I am assuming you already made sure to set the isolcpus setting).

You can mitigate this mostly by setting a fixed framerate using this option in the Makefile https://github.com/hzeller/rpi-rgb-led-matrix/blob/master/lib/Makefile#L105 - see instruction there for details.

Other than that, make sure additional stuff running on the pi is using the least amount of resources: e.g. don't use Python but rather C/C++, don't start new processes, but rather have a process that wakes up and gets to sleep, remove unnecessary processes (there are a few tips in the README), watch how much memory is being shuffled, to pre-calculation of things that can be precalculated etc.

[uros-skopus]

Thanks for very fast and quality response!

Firstly, yes I am heavily dependent on USB bus since I have 4 different USB peripherals attached to RPi. Secondly, yes, I reserved one of my 4 cores just for the refresh of the display using isolcpus=3 appendix at the end of the line of /boot/cmdline.txt. Also, I have tried all of possible tips from Troubleshooting chapter in README. Also, I had the same problem using C/C++ rgbmatrix distribution. Furthermore, I have integrated python image-viewer module within the very same process as my other calculations - both as a single python object and a separate Thread (same results). My other calculations uses round about 100MB of RAM memory. As you suggested, I've rebuilt python bindings with DFIXED_FRAME_MICROSECONDS value increased to 8000, but it looks like it was not done properly. Running python image-viewer module with --led-show-refresh option set gives me 6500 usec for single image display, ~ 8000 usec for just removing my mouse cursor around the screen and >30000 usec with my additional calculations running. It looks like DFIXED_FRAME_MICROSECONDS was not set properly even though I could see multiple lines during my build containing: g++ -I../include -Wall -03 -g -fPIC -DDFIXED_FRAME_MICROSECONDS=8000 ...

[hzeller]

Do you see if you run the regular demos in example-api-use/ that the properly do the fixed 8000μs ? I guess you have to sudo make clean and re-install all the Python bindings to make sure that everything gets pushed as needed.

You said two things that raised red flags as they do sound expensive and can cause flicker:

• "When I move my mouse"... This indicates you are running some sort of GUI system on the Raspberry Pi. Don't do that, the Pi is vastly underpowered for that and you will see flicker with that set-up. Make sure to set up a simple system, no GUI, just log in remotely via ssh when you modify things (see general suggestions in the troubleshooting section).

  • Python. Python is very resource intensive and will result in unpredictable memory use as it is a garbage collected language that can at any time consume some amount of CPU cycles and also cause memory churn. It sounds like your calculations do require a lot of memory churn if the refresh rate goes down to use > 30'000μs. Try to rewrite your code in C++. Python is good to test out things, but you really want to have your code written in a compiled language with predictable timing behavior for the final result.

You mentioned image-viewer; make sure to pre-calculate frames as much as possible and use the swap-on-vsync feature to swap in and out these images. In particular if you want to set an image pixel by pixel from Python, this will be a high CPU overhead. Even the led-image-viewer, written in C++, pre-calculates the images and puts in a frame as decoding of .jpg or .png results in too much memory churn.

Also, if there are things you can pre-calculate, try to do that. Strive to minimize CPU and RAM-churn use. If everything else fails, run your data extraction program on one Pi, then send over the calculated image to another pi just running a FlaschenTaschen server, updating the rpi-rgb-led-matrix.

[uros-skopus]

Thanks again for support and great answers! Firstly to comment all of yours proposals:

• "Do you see if you run the regular demos in example-api-use/ that the properly do the fixed 8000μs ?" Yes, after clean/install again. For some reason, even then, a bit higher value is recorded as max (8017 usec).
• After I removed rpi GUI part and other not needed libs and utils, my maximum refresh rate was reduced twice to the value of 17.000 usec. I followed your explanation what's the best way to examine the right value for this one. On steady state my Python image-viewer (after couple of minutes of stabilization) had maximum value of 6000 usec. On the other side, my maximum value for merged process with calculation and LED display control was 17.000 usec. Initially I set to 6000, and rebuilt, and afterwards played with number of different settings from 3.000 to the maximum 17.000. None of these brought any significant improvement. With lower values (3000 - 6000) image is clear, but with lot of pulsing flickering. With higher values (> 8000) image distortion starts to occur in the form of horizontal- lines flickering + plus a reduced pulsing. Can I really make any improvements with this setting having in mind my full setup? What about the other options (I have tried with slowing down pins - values 1 and 2, but again without success)?
• Replacing Python is currently just not an option, so I have to live with all side effects it brings with.
• "Make sure to pre-calculate frames as much as possible and use the swap-on-vsync feature to swap in and out these images." Take a look at my method for dynamically changing of displayed image:

  def displayImage(self, image_path):
      self._image = Image.open(image_path).convert('RGB')
      # Make image fit our screen.
      self._image.thumbnail((self._matrix.width, self._matrix.height), Image.ANTIALIAS)
      self._buffer.SetImage(self._image)
      self._buffer = self._matrix.SwapOnVSync(self._buffer)

  Within the same object's constructor I already initialized:

      self._options = RGBMatrixOptions()
      self._options.rows = 32
      self._options.cols = 64
      self._options.chain_length = 4
      self._options.parallel = 3
      self._options.show_refresh_rate = True
      self._matrix = RGBMatrix(options = self._options)
      self._buffer = self._matrix.CreateFrameCanvas()

  Can you please tell me if I am missing something regarding a sentence: "pre-calculate frames as much as possible."

I also have 2 additional questions:

1. I suppose reducing a number of LED panels in chain will improve results linearly. So for example if I reach total speed of 240 fps per module, and replace 4 LEDs in chain with 3 LEDs, I will have 80 fps instead of current 60 fps, so 33% of speed improvement?
2. How can I be sure rgbmatrix is using that single dedicated core to control refresh of the display?

[Beersatron]

You may find help by reading through a similar thread that I have from last year https://github.com/hzeller/rpi-rgb-led-matrix/issues/676

[uros-skopus]

@Beersatron Thanks for sharing your experience! Under your thread I've got answers how to check Cpu(s) usages and got confirmation regarding reducing a total number of LEDs in a chain. Also, you and me got significant improvement by using the lite version of Raspbian OS.

Nevertheless, the problem I have is slightly different since I must perform number of additional computation and communication with USB peripherals. I am just trying to figure out the maximum level of optimization to decide if RPi 3 B+ is really capable of running both in parallel.

BTW, I just figured out that my colors are mixed up - my blue is displayed as green, my red as blue...even if i set --led-rgb-sequence=RGB

[731mat]

I may have the same problem. Every 8 seconds, the image breaks down. starting with parameter --led-slowdown-gpio=2 without this parameter it doesn't work configuration: raspberry pi 3B LED module P5(32x64)

You have some idea ? how to fix it Thanks

[uros-skopus]

@hzeller You mentioned FlaschenTaschen server - but neither there I could find a Python support to send an image to a Tachen server running on other rpi. Am I wrong?

[hzeller]

it is a very simple udp protocol, but you also use the client api provided in Flaschentaschen. https://github.com/hzeller/flaschen-taschen/blob/master/api/python/flaschen.py

[hzeller]

@731mat Did you check the trouble-shooting section and disabled 1-wire ? Also, you picture looks like you jus thave trouble with the power supply as it starts to look bad when there are more LEDs on.