Outdoor refresh rate

First of all, thanks for all the previous work, I’m now able to use outdoor 64x32 mod8scan panels!

I’m using shield V4 with Teensy 3.6, maximum is 3 panels (64x96). The panels are part of a score-display, from time to time spectators want to make a picture or short video. For the human eye everything looks good but outdoor the average shutter speed of a camera is too fast,
partly lines appear.

Only with a very low shutter speed I’m able to make a complete image.

I tried different setting with setRefreshRate, 100 seems to be the maximum for my setup but it appears not different. Are there other options I can try? Many thanks.

From the looks of your first photo, you’d need at least a 10x increase in refresh rate to see a full image on the matrix at the same shutter speed.

There is a trade-off between refresh rate, brightness and colour depth. I’m not sure about Teensy 3.6, but on T4 you can set the colour depth in 3-bit increments. You should be able to increase the refresh rate significantly by dropping to 12-bit colour. See kRefreshDepth in the example sketches.

I’m not sure the T3.6 has the speed to work with crazy fast shutter speeds. As a reference point, on a 128x64 matrix my T4 gets 280Hz with 36-bit refresh, and 900Hz@12-bit.

When experimenting with this, it can be useful to regularly print matrix.getRefreshRate() so you can check that SmartMatrix isn’t throttling back the refresh rate.

Thanks for the reply, I wasn’t able of testing T4 but I will go for the V5 with the T4.

I don’t want to get your hopes up too high. I don’t have a camera capable of testing this. Is it right that in “sports mode”, under bright light, the shutter could be open for only 1/8000th second? Even 900Hz refresh would end up looking similar to your first photo on that time scale.

I was already on the limits of the T3.6 so swapping must improve something :wink:

Do you know if RPi have better results?

I’ve never used it, but I’ve heard good things about Henner Zeller’s rpi-rgb-led-matrix. The readme mentions ~100Hz refresh with 96 chained panels, so that may mean closer to 3kHz refresh for only 3 panels. I don’t know.

With the panels I purchased a Hanson RPi-MFC but my knowledge with the RPi is minimum. Now my score display is receiving data over Xbee so I probable need to redesign the hole setup then. Thanks for the link.

I agree with @sutaburosu’s advice, I suggest trying to lower the color depth first before switching platforms. On the Teensy 3 you can also set color depth in multiples of 3. Try lowering the depth and increasing the refresh rate until it’s able to sustain the refresh rate you like, and see if the number of colors available at that depth are enough.

1 Like

I’m very happy with how everything is combined right now so switching to a different platform is my last option :wink:

I checked the refresh rate, the maximum I can get is 120, lowering the kRefreshDepth further then 27 didn’t make a difference.

Changed the COLOR_DEPTH 24 to 12 but that gave a compiling error. I think it is caused by kPanelType = SM_PANELTYPE_HUB75_32ROW_64COL_MOD8SCAN. Edit: I think I didn’t understand this correct, COLOR_DEPTH 24 remains and adjusting goes through kRefreshDepth.

Can you give a hint what to try next?

Edit 2: With some more testing I was able to reach 180 with kRefreshDepth 9. That seems to be the maximum, unfortunately not good enough. Hope the T4 gives better results

What is the max frequency you get with SmartMatrix on the different controllers? I want to say the max for the Pi is somewhere around 12-18MHz. I think I saw 12-14 on Pi 2, but I do not recall exactly.

You trade pixels, bit depth and FPS. However there could be power supply issue depending on certain factors. For example 32x16 panel with 4 BCM bits of depth could get around 2929 FPS assuming 12MHz. PSU could see 0.9-1.8A at 46.8kHz per HUB75. This is kind of aggressive. With 8 bits BCM the FPS drops to 183 and the PSU drops to 5.9kHz, which is more reasonable. PWM (aka naïve-PWM) makes this even more stable. Longer chains increase the load but lowers the frequency until multiplexing breaks down, which would be around 800Hz for this.

Does this sound reasonable to you?

I hope this question is for Louis, its a bit above my knowledge :wink:

It is. I am not sure the exact answer myself. However I suspect there is a worst case condition if you make square wave using BCM bits. Generally speaking it never matters. However it can cause issues. I am curious if Louis knows or has experimented with this.

My thinking is FPS times Multiplex times BCM bits divided by 2 represents worst frequency for PSU. Standard PWM is BCM bits divided by two times better, however is computationally very hard. For most of the use cases this never matters for BCM. This avoids need for expensive hardware and other stuff.

I also have reasons to suspect another trade off exists in multiplex and bits of depth in terms of current/brightness division for LEDs. Regardless of CIE1931 or perceptive brightness. This would not hold for outdoor panels of course which have more than higher density panels using more multiplexing.

Edit: Outdoor panels generally force longer chains which improves the PSU frequency. For the same number of pixels you increase the columns rather than the multiplex. The lower multiplex improves current/brightness per pixel. This does increase the load but lowers the frequency on the PSU.

In a more realistic usage the frequency will not be this extreme. However it can be. Bulk and/or decoupling caps can be used to average the power draw into a larger lower frequency load for PSU. This is again outside my wheelhouse but I know some consideration is required.

In my testing, you need 400-500Hz referesh rate for pictures to look ok with most cameras.
My own big array is only 100Hz because it has 100k pixels, and I have to use a special camera with special settings to get video without refresh bars.


Same refresh rate, but second one uses an RX100M7 with manual settings I set to use a slower frame rate on the camera.

cell phones in daylight are tough because they might take a shot in 0.001s because they have enough light, honestly outside of running with an FPGA at 1000Hz, there may not be an answer there. Thankfully my stuff is mostly used at night where cameras automatically use longer exposures and things work out on their own.

It may not need to be clocked that high. However one may be able to get with 33MHz. Max quality would be about 10 bit PWM for 1kHz on 1:32 multiplex. (Rough guess) Less quality will enable high refresh at lower clock. Possible without FPGA if careful.

This is problematic on the Pi. May work on Teensy till memory runs out. FPGA has different tricks it can use. For CC LED drivers its pointless outside increasing bandwidth. Which comes with other problems.

In theory, PWM or MM LED driver could get what you are looking for. I am not about to repeat myself. There is a lot that can be done to get the refresh rates higher. Certain platforms are more capable than others.

I agree with this answer for CC based LED drivers. Lowering the chain length is another option. The only thing a FPGA can do is increase parallel chains for larger displays. However this is costly and has low/medium quality. You could try using multiple controllers.

FPGA can avoid BCM, which may have benefits to PSU.

That sounds great, please post your code to show us.

I should clarify. MCU could in theory use S-PWM (used in many MM drivers) to improve refresh rate. However this only works if you have low latency memory and DMA. The number of interrupts could become a massive problems.

Which could be resolved with the following:

  1. Low HUB75 speed
  2. Fast processor
  3. Long serial chain

In most cases this is too problematic due to stability concerns. This makes the most sense against a certain chain length and quality need. Very niche implementation. RPI likely will never be able to do this without significant effort.

Note BCM is technically possible with this but only helps with certain things. It lowers the amount of work and size of bit planes. However the number of interrupts is very high, if you waste refresh the number of interrupts can be kept low which helps with stability and frees time for other things.

You still have potential issues with BCM at LED driver layer with this approach. There is also an increase in overhead with this approach from dead time required between row switches potentially. (Aka ghosting prevention.)

It would be cool if someone added support for PWM/MM drivers but I have found using a receiver card directly is much more cost effective and offer better performance/quality. There are cases where this is not the case and I stand by my assertion that these are possible on the Pi and MCU. However only make sense in specific cases.

Note refresh is actually higher for S-PWM .