Very minor brightness dip (randomly)

[ukdepartureboards]

Hello

My setup is the following

• Raspberry Pi3 B
• nodejs sending 192x32px frames to rpi.rgb c process via a socket at 30ms intervals
• nodejs makes a small wifi http request every 10sec
• viewing logs via ssh terminal

every so often the display brightness very slighty dips. As if the cpu time is being taken away from the rpi.rgb process even though its on its own isolated core. (should nodejs be launched on its own core?)

If i stop node the image is 99% stable.
nodejs is using around 2% cpu and rpi.rgb is using 67%

It appears either nodejs/socket or the wifi http request upsets it some how occasionally?

Also on the rpi.rgb end i am having to loop all 192x32 pixels to the rpi.rgb frame buffer with the setPixel method, as my stream of data is simply [r,g,b,r,g,b........] format is there a faster way to map the data onto the rpi.rgb frame buffer to remove this loop?

Regards
Russell

[ukdepartureboards]

Looks like the isolcpus=3 may not be working correct (i did add to the end of my cmdline.txt)
As it appears the 'app'(this is my rpi-rgb c++ process) is running on core 2 (and so is node and few other bits and bobs) might explain the brightness dips as cpu time is taken away from the app.

Any ideas why the isolcpus=3 is not working?

here is my cmdline.txt
'dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=3e03c819-02 rootfstype=ext4 elevator=deadline fsck.repair=yes isolcpus=3 rootwait fastboot noswap ro'

Regards
Russell

[hzeller]

only the refresh thread should run on core 3, not anything else. You can see the core load distribution by pressing '1' in top. And the thread assignment with 'H'.

[ukdepartureboards]

Thanks for the reply. I have found htop seems to show it a bit clearer, which does show it on core4 by it self. If the refresh is on core4 by it self nothing should be able to take cpu time away?

[hzeller]

yes, it should not, but the kernel is still free to schedule kernel tasks and answer interrupts there.

(core 4 is the isolated cpu 3 btw, just counted from one).

[ukdepartureboards]

Ah i see so basically isolcpus=3 is telling the kernal to just leave core4 alone, and your refresh thread runs on core4 for best performance, BUT the kernal can still interrupt if it wants?

is there any way to make it 100% isolated?

Regards
Russell

[hzeller]

If I knew, I'd tell you :)
Testing a realtime kernel might be an option.

[ukdepartureboards]

Thats next on my list hehe :)

Can any of your settings help improve performance ie slow down or pwm bits? or this would be minimal boost?

I have also noticed when the nodejs app is paused (ie not sending frames) the image is very stable no dips. But when running (sending frames at 30ms intervals) the image does dip in brightness randomly only very slightly but enough its noticeable. The nodejs is on a different core so shouldn't have any effect on the refresh core. Im wondering if my socket/update frame routine could be improved?

Regards
Russell

[hzeller]

I suspect there is actually someting limiting the hardware on the Pi, e.g. some shared bus like the memory bus that is being taxed when sending stuff over the network or the node.js is doing garbage collection. So in that case, even 100% isolation would not help us.

I am experimenting with something, maybe something to try soon.

[hzeller]

Check out the new compile-time option in FIXED_FRAME_MICROSECONDS in lib/Makefile. It will allow to time-buffer glitches created by the rest of the system.

[ukdepartureboards]

I will give this a go asap!

I was having a play last night and found a higher pwm_lsb_nanoseconds value minimizes the issue (does not completely remove it though). I was on 130 but switching to 200 has definitely helped and 300 was even better. The only downside is my frames consist of scrolling text. And it appears the higher the pwm_lsb_nanoseconds value the more stuttery looking the text looks as it scrolls but with a much lower value ie 130 it scrolls perfectly smooth. So its a bit of a trade off at the moment between slightly stuttery text vs minor display glitches hehe.

I also noticed if i had nodejs send one static frame and then close nodejs, the refresh is 99.9% perfect just the occasional very minor glitch. But if i run nodejs on another core (not sending frames, just running its logic) the glitches are every few seconds. So even though its on a separate core the process is certainly impacting the refresh core.

I have also come across this which appears to be a compiled ready to go RT kernel so will be testing this out soon as well https://github.com/guysoft/RealtimePi

Regards
Russell

[ukdepartureboards]

I added that flag, and monitored the refresh rate and my worse case was 8120 so I set the flag to 8500 to be safe and iv sat here for 5min now and it perfect! Not seeing any glitches at all! Ill perform a few more tests but its looking extremely promising :)

I am running
res: 192x32
pwm-bits: 11bit
pwm_lsb_nanoseconds: 130
DFIXED_FRAME_MICROSECONDS: 8500
slow-down: 2

sending frames from nodejs (on another core) at around 30ms intervals

I think I can lower the value as its nodejs start up with causes the most glitches after startup it settles so ill probably get away with 6500 or so, ill keep playing :) (only very minor down side is it makes scrolling text look every so slightly jumpy but very minor, i just need to find the right balance :)

so between using pwm_lsb_nanoseconds / DFIXED_FRAME_MICROSECONDS i think 99% of glitches can removed :)

Thanks for the great work! (and excellent support!)

Regards
Russell

[hzeller]

Glad it worked!
I would still try the Realtime kernel and see if less (or no?) adaption of this value is needed.

[hzeller]

Another question: you say you are having a 192x32 panel. Is this just a single chain with 6 panels of 32x32 in a row ? The longer the panel chain, the more susceptible the panel is to slight flicker as more time is spent in clocking-in the data.

If you can, you should consider making this three chains (e.g. by connecting it via an adapter (there are also some external vendors that sell boards that are compatible with my library).

Then, you can arrange the panels in this way where you connect them around the corner, with two panels connected forward, around the corner and backward. Then three of these arrangements:

  [<]-- Parallel chain #1
  [>]
  [<]-- Parallel chain #2
  [>]
  [<]-- Parallel chain #3
  [>]

Then, use the U-mapper pixel-mapper and the 90 degree rotation to make the whole arrangement behave like a 192x32 panel instead of an upright 32x192:

your_program --led-chain=2 --led-parallel=3 --led-pixel-mapper="U-mapper;Rotate:90"

This way, the longest chain is only two panels long, which in general will give you a little more refresh rate and possibly less flicker as baseline.

(There is more documentation for the U-mapper; you might need to get the latest version of this library as only recently I made it that simple to use with command line flags).

[ukdepartureboards]

Tweaking DFIXED_FRAME_MICROSECONDS has basically solved the problem for me :)

Yes i did think about this (i use x3 64x32 panels) in series. I have already designed/made the pcb hardware (only one output) so using 3 output cables is not an option at this time but definitely another option for the future

Thanks again for all your help :)

[hzeller]

Alright, I guess we can close this then.

Please update this thread if you happen to try the RealtimePi and see if it reduces the tweaks that need to be done with the FIXED_FRAME_MICROSECONDS. Some people with similar flickering issue might be eager to know :)

[ukdepartureboards]

Yes indeed, I will report my findings :)

Regards
Russell

[TheGigaQuant]

Tried with the FIXED_FRAME_MICROSECONDS and it reduce a lot variations of frequency for fixed things or even scrolling text.

[TheGigaQuant]

Tried with the RealTime Kernel on RPI 4 4GB and it works well but I still have a little flicker issue when I'm viewing videos