Whats the bottleneck for refresh rate?

[ArsalanDotMe]

I have a Raspberry Pi 3 with the last core reserved for this library as stated in the instructions. I am trying to control a 128x64 pixel matrix comprised of two parallel chains of 32x32 matrices. I am only getting a refresh rate of around 170Hz on my Pi3 and can notice visible flicker every few seconds. I am using a slowdown value of 2.

My question is, is the brightness flicker (seen once every few seconds) due to a performance bottleneck of Pi or is the bottleneck somewhere else? How can I improve it?

[hzeller]

Please read the section about 'changing parameters' which influence your refreshrate and how to tweak it.

Regular flicker every couple of seconds can be triggered by the kernel; make sure to run as little as possible other programs on the Pi. You can even see flicker when being logged in via ssh and typing - I suspect the Pi has to share memory bandwith internally and runs into limits then. Use the isolcpus bootup parameter (see README) to make sure to lock the display update onto one core.

[ArsalanDotMe]

@hzeller I've done all the optimizations stated above, and I have even installed a real-time kernel for the pi. The flicker every few seconds is still there and it seems that this implementation with a Raspberry Pi is not feasible in a 'production system' with a resolution of 128x64. There are some chinese controller cards that cost a few hundred dollars that work really well but I can't program them myself. They are operated with a Windows software that they supply. Now my question is getting out of topic for this library, but is there any way that you know of where we can use a Pi to pull images from somewhere or generate them on the fly, but have some dedicated hardware take care of refreshing the screen at very high framerate?

[hzeller]

I have found, that realtime kernels actually do worse, so I am not recommending them anymore (there is a problem with the USB controller in the Raspberry Pi which creates 8000/second interrupts with the realtime kernel, using up a considerable amount of CPU). Try the standard kernel and a minimal installation, like a Raspbian Lite. Do the isolcpus setting. Read the README and the troubleshooting section; if you have any other software that attempts to use the hardware PWM generator, switch it off. Remove any daemon from the Pi that you don't need.

I have seen the 'every two second flicker', but only when maxing out the refresh CPU to 100%, because then the kernel interrupts it (so if you have too low PWM-nanoseconds, have only 1 bit color for instance). You can see that in top (but if you are running top, you actually see a flicker whenever top updates). Try to tweak it so that you only use 90% CPU on that thread.

I am operating a 160x96 panel in a 'production' environment without problem on a Raspberry Pi 3 without problem (see the image of the panel in the README; it is three parallel chains with 5 panels each). Even though the other cores are mostly free, I would not do too much other processing on the Pi though; I usually send images via the FlaschenTaschen protocol to it.

That said, you can of course build a dedicated system with some frame memory and a CPLD or FPGA to do the same thing for probably not more than the hardware cost of a Raspberry Pi (plus the time for design and boards you need to put into).

[ArsalanDotMe]

That's great information! Unfortunately, I never ran much tests with the standard kernel, assuming that the real-time kernel would be automatically better. I have seen CPU usage of mostly around 70-80% and a refresh rate of around 170-180Hz. Another useful information to disclose is that I'm using the led-image-viewer in the utilities folder to just cycle through some images. Reading your response, I will now try again with the standard kernel, and will also try other demos. I do think I remember the rotating cube demo running pretty well, so maybe the issue might just be with the image viewer. I'll run some tests and verify.

Other than that, thank you for writing this wonderful library. I went through the code briefly as well and it was written and organized very beautifully. I had very little problem in understanding what I read, even though the only C++ experience I had was from a semester in college. I'm looking to dive a little deeper into this and might just try and build a system with the FPGA involved (even if it isn't needed for my application). I'll go through your code to understand how it talks to the LEDs but if you have any resource that details how these panels are driven, that would be awesome.

[hzeller]

Using the led-image-viewer is fine as it preprocesses all the scaling and preparing the frame buffer initially, so it will not really use CPU in operation. This is recommended if you want to show a sequence of images.