Brightness jumps up and down

[thetechknight]

I noticed when I leave the pi sit on a demo, say the Simple Square demo., the brightness pulses up and down once a second.

Using the adafruit hat, and I did the mod to it and changed it to adafruit-hat-pwm and it really didnt make a difference.

This is driving me nutso. any ideas? I tried isolcpu command as well.

[hzeller]

Did you read the troubleshooting section that goes through a couple of topics what to do here ?
You probably have some process running that uses memory bandwidth, 'stealling' it from the rgb-matrix.
If it is once a second, maybe you have a top running somewhere ?

You can also even out time variations by measuring and setting the FIXED_FRAME_MICROSECONDS value in the Makefile and re-compile.
https://github.com/hzeller/rpi-rgb-led-matrix/blob/master/lib/Makefile#L105

[thetechknight]

Yes I did, that was the first thing I did. I am running the Raspbian lite Jessie with the sound turned off and some other things turned off.

I dont know what top is so I am unsure how to proceed there. Maybe I need to drop the isolcpus down to 2? but I dont see where the core gets assigned to the rgbled matrix as a dedicated core unless its compiled in somewhere.

Also I can stop it by changing the microseconds flag to around 550 or so at the command prompt, but when text is present it brings in alot of sparkling/pixel mal-discharge which I dont know whats causing that. I can get rid of most of this by going up to 1000 or so but it seriously affects the framerate. My GPIO slowdown is already at 4. if I go up to any higher, especially at 1, the screen is a scrambled mess of pixels. haha.

I am only using a single chain of 8 16x32 modules and thats it. I have it formatted as a 128x32 display using the S-mapper mod that the other guy posted.

[hzeller]

The isolcpus value needs to stay at 3 as it is the core we want to isolate and run the update on.

There is no microseconds flag (there is only the PWM nanoseconds, but that is something different). If you want to eliminate the regular flicker, you need to follow the instructions in the Makefile and modify the compile-in value of FIXED_FRAME_MICROSECONDS that suits your set-up.

[thetechknight]

ok, thank you for the information. Greatly appreciated.

[thetechknight]

So I did what you mentioned, my longest time was 7790. So I chose 8000.

I did a sudo make clean all, Uncommented that line and changed it from 5000 to 8000.

Did a save, then sudo make all. It made no difference, its still trying to show 6XXX usec and then jumps to 7790 again, and I see the brightness flickers again. So its almost as if that flag did nothing?

when it was scrolling through the screen during the build, I saw the 8000 in there in the flags for each compile.

thoughts?

EDIT: I did the make-python, install-python and it worked that time. Wonder why make all doesnt work?

[hzeller]

So if you have changed the setting, you would see it show up in the compilation lines, e.g here you see the 8000.

  g++ -I../include -Wall -O3 -g -fPIC -DFIXED_FRAME_MICROSECONDS=8000  -DDEFAULT_HARDWARE='"regular"' -Wextra -Wno-unused-parameter -fno-exceptions -c -o led-matrix.o led-matrix.cc

I suggest not to run sudo make all, but only make or make all. With the 'sudo', you are writing files that can not be removed by the regular user. Use 'sudo' only for make install
(to fix the outputs of sudo make, you should run sudo make clean in the toplevel, so that all the files written as root are removed. Then just type make again).

Anyway, once you have compiled that, the output of --led-show-refresh should never really show numbers below the chosen 8000, if so, something went wrong in the compilation process and you should make clean first.

[thetechknight]

Thanks for the info. Is there any way to make this a runtime flag? I keep having to circle back around to it over and over.

I am at almost 9000 and its stable until I start a text/picture loop. When it goes to load the PNG file it flickers, and jumps past 9000 when it does.

I was loading the PNG across a network share, so I did away with that and put the file on the same directory as the python file and it didnt make a difference really.

[hzeller]

It could be made a runtime flag, but right now it is just a compile-time flag to see if it is useful (but a few people already found it useful, so when I get some time ...).

In general, make sure to minimize memory bandwidth inside the Pi as the limited hardware of the Pi seems to not be able to keep up with internal busses. Some suggestions:

• Don't decode images such as PNG files on-the-fly, but consider pre-calculating them and keep in memory as frames.
• Consider using the content-streamer-abstraction to prepare frames in-memory or on-disk.
• Look at the code for the image-viewer (led-image-viewer.c) for these tricks to be applied, as even in C++ on-the-fly processing of images can generate flicker. It also allows to write and read a stream (see content-streamer above). The video-viewer also allows to output the content as stream for jitter-free playback.
• Avoid to use Python as it will randomly create huge memory bandwidth peaks when it does the garbage collection and create flicker. In general it also uses more CPU and memory bandwidth for the same task compared to a compiled language such as C++.
• Alternatively, you can prepare the images remotely and send via a very simple protocol to your system; I usually use the FlaschenTaschen protocol for this, for which I have also written a server that can output to the rgb matrix.

[thetechknight]

I dont program in C/C++ and can barely understand it when trying to read it, so that options out off the table for me sadly. Took classes in school and almost failed it.

VB stuck much better with me, and surprisingly procedural PHP.

I dont know Python that well either, but I understand it better than I do C so thats what I stuck with.

I understand your statement about precalculating a PNG, but programatically dunno how.