Persistent Flickering Issue on 16x32 RGB LED Matrix

[squidKid-deluxe]

I'm currently working on a MIDI sequencer project using a 16x32 RGB LED matrix in conjunction with a Raspberry Pi Zero (original 1.3). I've opted for the python bindings of this library to control the matrix. Previously, I encountered performance issues using a 128x64 matrix, where the Raspberry Pi Zero struggled, yielding approximately 2 fps. I switched to the 16x32 matrix, and while the performance improved, a persistent flickering issue emerged (see images here).

I've taken several troubleshooting steps, including unplugging all peripherals from the Pi except for power, experimenting with the gpio_slowdown feature of the library, and meticulously checking my connections multiple times. Unfortunately, the flickering persists.

Below is the setup code I'm currently using:

from rgbmatrix import RGBMatrix, RGBMatrixOptions
from PIL import Image

options = RGBMatrixOptions()

options.rows = 16
options.cols = 32
options.hardware_mapping = "classic-pi1"
options.multiplexing = 3
options.pwm_bits = 11
options.gpio_slowdown = 4
options.show_refresh_rate = True
options.pwm_lsb_nanoseconds = 1000

matrix = RGBMatrix(options=options)

The only multiplexing value that displays correctly is 3, and I've experimented with various values for pwm_lsb_nanoseconds without success.

To write to the display, I use the following code snippet:

matrix.SetImage(Image.fromarray(buffer))

Where buffer is a 16x32x3 uint8 NumPy array.

The flickering issue is significantly affecting the usability of the display. I would greatly appreciate any suggestions or insights into resolving this problem.

Other thoughts: EMF? Bad Ground?

Thank you in advance for your assistance!

PS: I have also posted this to the Raspberry Pi forums, I will keep an eye on both channels.

[hzeller]

You are using the classic pi mapping which is very outdated and was only used in the very first version of this library on the very first Pi. That mapping doesn't use a output-enable pin to allow for flicker-free PWM. Wire up your board to regular type. Even though the Pi Zero has the CPU of the classic Pi, the pinout is the standard 40 pin kind and should work with that.

Without that, it will always flicker. In particular on the single-core slow CPU the Pi Zero has.

Also I suggest to use C++. The Pi Zero is too underpowered to be useful with using Python: even if the performance seems sufficient for your application, the garbage collection cycles will inevitably lead to flicker. Everything is running on a single core on the machine, and the display needs constant updates.

Consider --led-limit-refresh to create an even refresh rate that allows for some CPU-time for your processing in-between. Lower PWM bits can also help the slow CPU.

If you load image: pregenrate the framebuffer and use from there, otherwise each image decoding will already be noticeable as flicker.

So to summarize

• Use a hardware mapping that allows for PWM (I suggest the standard regular mapping)
• Play with the options affecting refresh rate and flicker (the README has a lot of such suggestions)
• Try to avoid Python if at all possible.
• Of course, if you can, use a Pi with more and faster cores but I suspect Pi Zero was part of the hardware requirements.

[squidKid-deluxe]

You are using the classic pi mapping which is very outdated and was only used in the very first version of this library on the very first Pi. That mapping doesn't use a output-enable pin to allow for flicker-free PWM.

Noted, I ended up there from following this tutorial, but I think I may have changed the pinout file of this library (probably shouldn't have, but the 128x64 matrix required an extra ABCDE pin) to include the OE pin. Will switch to regular.

I have indeed played with lots of options, I didn't see the --led-limit-refresh you mention, but I will try it.

As for not using Python, I am definitely not a C++ dev, so is there any way to run my main code in Python and have some sort of connection to a C++ backend? I thought the Python bindings where inherently doing that. Thoughts on that and whatever kind of pipe between are appreciated.

A bigger Pi would be great, and though the Zero is not a hardware 'requirement' per se, I am trying to shy away from increasing the project budget still more. (This would not be the first time I needed more parts...) The Pi zero was $15, a bigger pi, even a 3B, quickly gets upwards of $40.

If you load image: pregenrate the framebuffer and use from there, otherwise each image decoding will already be noticeable as flicker.

I don't load the image, there are actually multiple threading.Threads sharing numpy arrays through a dictionary, each Thread indexing their individual array and changing elements. Then, in the main thread, I add up each array (with some np.where magic for precedence) and display it. If you need, I can give you a much more detailed description of the project, I was trying to keep the issue short and skinny, but I have a ~3500 word writeup on what is going on.

EDIT: The wiring guide seems to suggest that only one ground pin is needed. Is this the case Or should I wire in all three?

[squidKid-deluxe]

Does seem like processing power is the issue, as lowering the PWM bits to the 1-3 area seemed to fix 99% of the flicker. I plan to acquire a faster Pi soonish, maybe even the newly released Pi 5. Leaving this issue open for now, until everything is fixed.

Maybe I'm being superstitious and incorrectly detecting random patterns, but it seems to flicker more when the sun is out...?

[hzeller]

Note, I have not adapted the lowlevel gpio stuff to Pi5 yet, so right now, this won't work. Pi4 should work fine.

[squidKid-deluxe]

Is that a priority? In other words, is it worth getting a Pi 5 now and waiting for the library to update, or is that not something you intend to do in the near future and I should just get the Pi 4? Because this project is in no particular rush (I'm totally willing to wait a few months before getting a faster pi) and I'd prefer to have the fastest available Pi in case I want to use it for other things too.

For that matter, is it just a case of changing the GPIO pins in lib/hardware-mapping.c and I'm good to go, or is there something bigger than that looming?

[bitslip6]

GPU support for PI zero is available here. The GPIO map address needs to be updated for PI zero, which should be done next week.

https://github.com/bitslip6/rpi-gpu-hub75-matrix

[mrechte]

Hello. I setup a 128x32 (2 x 64x32 dots) DMD on a Rpi 3B+. I tried all the tuning options to avoid flickering, but it did not work.

The software config is as following:

• a small dmd-server that receive frames to display from a UNIX socket
• MPF-MC (tweaked) that prepare frames and send them to the dmd-server.

Flickering happens only when MPF-MC (which is a Python application) is running. When both run, CPU usage is not excessive.

So my question, is there any hope to improve this, should I move to Rpi 4 ? Also could rpi-gpu-hub75-matrix help, in such setup, with a Rpi 5 ?