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.

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.
See

vs

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.