rpi-rgb-led-matrix
rpi-rgb-led-matrix copied to clipboard
--led-row-addr-type=5 for ABC panels works with slowdown 2 with Raspbian 4 or but with Dietpi, requires unchained panels or slowdown 3 => we need fractional slowdown factor?
First, I'll extract this important bit. addr-type=5, for 128x64 panels with the "go fast" options I'm giving below, works up to 236Hz. If I got faster, just a bit faster, because of a better compiler or kernel (with the same code), refresh rate jumps to just a bit faster, and the shift register goes out of sync and stops working. making slowdown higher works, but fractional slowdowns would be better.
More details: I'll fork this off from https://github.com/hzeller/rpi-rgb-led-matrix/issues/1774 @board707, type 5 is definitely better and works with a smaller slowdown, but here is what I found out
My setup is active-3 board (with level shifters), 3 outputs of 128x64: ~/rpi-rgb-led-matrix/examples-api-use/demo --led-slowdown-gpio=2 --led-panel-type=FM6126 --led-rows=64 --led-cols=128 --led-row-addr-type=5 --led-chain=1 --led-parallel=3 --led-show-refresh --led-scan-mode=0 --led-pwm-bits=7 --led-pwm-lsb-nanoseconds=50 -D0
Here is what I found:
-
slowdown 2 works rPi3a running Raspbian 4 or Rpi0 2w, running Dietpi 6 but not rPi3a running dietpi (at all, whether panels are daisy chained, or not).
-
now I actually have 3 more panels chained one deep on each channel P1 - panel1 - panel2 P2 - panel3 - panel4 P3 - panel5 - panel6
But this is where it gets "interesting". I do not tell the lib to output more pixels. I keep the chain at 1 and I rely on panel1/3/5 bits being shifted out by the next plane, to display on the 2nd set of panels for "free" (no more compute needed, same refresh rate).
2a) with rPi3a and raspbian 4 (kernel 4 and 32bit), the 2nd set of panels work great with slowdown 2. I get 236.0Hz, a bit slower than 2b below.
2b) same config, if I boot Dietpi 6 (kernel 6 and 64bit), both sets of panels are super damaged (the line selection is clearly wrong), whether I plug the 2nd set of panels, or not. So the same rpi3a hardware with your same code and same everything, work with slowdown 2 on raspbian 4/kernel 4, but not dietpi 6/kernel 6. Clearly the compiler/and or kernel do different things timing-wise and it breaks your code (maybe it's just too fast). I get 269.4Hz, a bit faster than 2a and I guess too fast.
This is another to say that dietpi 6 is faster on that hardware and throws the signal out of spec, by a lot.
- now I switch to rpi02wl, it gets even more interesting
3a) if the daisy chained panels are not plugged in, it works with dietpi6 and slowdown2 I get 248Hz, the display is almost ok but apparently the extra 12Hz over 2a, is just too fast if panels are daisy chained, but if they are not, the first set of panels is flawless. So another way to say this is 248Hz works, but the extra noise/capacitance fed by the output ports by the mere act of daisy chaining, is causing 248Hz to be just too fast and look like this. Interestingly the mirrored panels are on the right right and look better than the original panels
3b) I switch to slowdown 3 but now the speed is down to 228Hz or so and display works.
So I think I figured out my own problem and own solution:
--led-row-addr-type=5 helps going faster, but still hits speed limits that don't happen with ABCDE. If we cannot go faster without upsetting the shift register logic, we need a fractional slowdown so that we can go just as fast as the hardware will allow.
I had a quick look at the code, haven't yet found where slowdown is used to do actual slowdown, only found
./lib/gpio.cc: slowdown_ = slowdown;
not sure if slowdown can be made fractional, or not.