Slowing MCU to reduce or eliminate flicker on multiplexed LEDs recorded by normal rolling shutter CMOS camera

Apparently the speed of the MCU has an effect on the speed of an LED multiplexer chip like the HT16K33 or MAX7221 or whatever and the speed of those chips determines the refresh rate of a matrix display or whatever LEDs they're running, right? And the interaction between the refresh rate of those LEDs and the "shutter" speed of a rolling shutter CMOS determines how messed up it looks on camera.

I was thinking, could a way to minimise or even eliminate the interaction exist in deliberately slowing operations on the MCU? Like, if a potentiometer determined the length of a delay in the MCU code, could it be possible to find a rate of operations on the MCU that would look okay on a rolling shutter CMOS? Assume that the MCU isn't doing things that will vary it's speed so the only source of variation comes from the potentiometer setting and use a 30-turn pot so the reading doesn't jitter so much?

No, that is false. Such chips have an internal oscillator that runs completely independently from the MCU clock. It dictates the LED refresh rates.

You would learn that from a little bit of experimentation... as well as the data sheets.

Is it not possible that some MCUs (i.e. 328s) are too slow for the multiplexer to run at full speed? It was a comment I saw here on Reddit that made me think such: https://www.reddit.com/r/AskElectronics/comments/zvptfd/comment/j1qftcs/?utm_source=share&utm_medium=web2x&context=3

Read what I said again.
https://thedecisionlab.com/biases/dunning-kruger-effect

The MAX7221 datasheet says the scan frequency is between 500 and 1300 Hz. Is the variation caused by manufacture inaccuracies of the oscillator?

That is entirely possible, because those on chip oscillators are RC based.

If you are making a display with the intent of photographing it, then do not multiplex the display. Some portion of a multiplexed display will always be off while another portion is on, so unless the multiplexing rate is extremely high compared to the shutter speed, there will likely be noticeable effects on the camera.

I think it is completely wrong suggestion. In contrary, to minimize the flicker you should increase the refresh rate as much as possible.

...or doing that as quickly as possible...

Just yesterday I try to photo a RGB LED matrix with quite new smartphone. I can see remarkable flickering until i set the refresh rate above the 400Hz

You couldn't speed it up unless you'd already chosen to operate at a lower frequency for some reason. And I believe it makes sense. If your camera's shutter was 40 Hz and your project flickered at 60 Hz, you'd get a flicker. Slowing down the project to 40 Hz would make it not flicker.

What was your project that gives control over the refresh rate?

Incidentally, I've found a chip called TM1681 which allows an external signal to control its refresh rate. The pins of interest are 15 and 20. Unfortunately, the datasheet is in Chinese.

I'm playing with the P9813 PWM LED controller. One feature is a scan rate in the several kHz region, said to be specifically intended to eliminate camera flicker.

No, but then it would "roll". You only slowed down the flicker. It would remain visible unless it's perfectly synchronized to the camera frame rate.

Many cameras do not collect light for the entire frame duration, sometimes it's only thousandths of a second. So even if your frame and display scan rate are identical, you would see only a few of the LEDs illuminated at a time (a "stripe").

So not only would it roll, but it would still be visibly disrupted.

Try it and you will see that you are mistaken.

I agree that faster refresh is what you want. It's like flash high speed sync. Refresh should be so fast that for each line of the camera sensor, each LED that's on would be on for the same amount of time. Fast enough that off-by-one isn't material.

Edit: Here's a video taken with a 30fps camera showing gradual speedup of the refresh rate for a 7-segment display, with multiplexing by segment. The final refresh rate that produces no flicker is every 2ms, or 500 times per second. But since each segment is only lit up 1/7 of the time, that's 71Hz for any individual segment.

https://youtu.be/8w09Zy8MQrc?t=309

I don't know what the refresh rate of the MAX7221 is, or whether you can control it, but I'm kinda surprised that you're getting flicker with a normal video camera.

Worst case, rolling shutter scans horizontally, LED matrix scans vertically. The LED would never have the time to scan the entire vertical column in the time the shutter was viewing that particular column. You would likely end up with diagonal rolling of the display in the image.

If both scanned in the same direction, then unless you have exact synchronization so that the column the shutter is viewing is also being lit on the LED array, you will still see rolling dark bars in the display.

Remember, when a wagon wheel is exactly synchronized with the frame rate of the camera, the wheel appears to be motionless, or very slowly rotating forward/backward if slightly out of sync.

TM1681 and HT1632C seem to both be the same chip made by different companies. They have OSC pins to which an external oscillator can be connected - it's meant so that multiple chips can operate in sync with each other but I was wondering, could it be possible for me to attach an astable 555 that could be adjusted to "overclock" the LED driver? Would it be likely to be damaged if I tried to run it at twice the intended speed?

More likely, it would just refuse.

Okay, thanks. So long as the magic smoke stays in, the fun can continue.

My opinion, you won't have any real fun until you eliminate multiplexing. I realize that isn't what you want, but the proposed fixes are more concepts than solutions.

Not all LED matrices can be launched without a multiplex, maybe OP has no other option.