Pretty terrible flicker at 64x64 with teensy 3.2

#1

So, first, is it fair to say that the shift registers on those panels are fast enough that they are not the limiting factor for the refresh rate, and that only the teensy, is?

If so, at 64x64, with both 32x64 at 1/16 with 2 panels which makes it 1/32, or 64x64 1/32, the flickering is visible with the naked eye and bad enough that most pictures are garbage, while a video is so bad that I stopped recording.

Is it fair to assume that if I switch to a teensy 3.6, the faster CPU will fresh the screen more quickly (4x faster more or less?) and hopefully refresh the screen more quickly than my camera is taking frames?
Currently 32x64x2 runs at 53fps according to the counter in the demo and strangely 64x64 only tops out at 49fps

FastLED allows running multiple Neopixel strings in parallel to get around fps issues (thankfully the LEDs keep their values and don’t flicker). Has anyone used smartmatrix in a way that 2 or 4 panels are run in parallel, using more pins on the teensy, or doing this in parallel would just divide the fps by 2 or 4 because it’s processor limited anyway, so ultimately it would be no better than the current chaining mechanism?

Current flicker examples:
image

image
image.jpg1584x1188 1.09 MB

Thanks,
Marc

#2

In the example you’re running, the Teensy is the limiting factor. I’m not sure at what point the panel refresh rate becomes the limiting factor.

I personally won’t be happy with viewing anything below 120Hz refresh. Trying to get that out of the Teensy 3.2 at 64x64 isn’t going to happen. You can try to drop the color depth to 24 from 36, but you’re likely still getting flicker.

A Teensy 3.6 should handle larger panel sizes much better, but I can’t tell you off hand if you’re going to be able to get >120Hz refresh with a 64x64 panel.

The limitation is mostly CPU to calculate the data used for refreshing the panel, and not shifting out the bits. On the ESP32, you can separate out the calculation from the refresh, so you could refresh at, let’s say, 250Hz while only updating the frames at 30Hz, and there’s a lot less CPU overhead.

#3

Thanks for clearing that up and confirming the target fps I want to get a visually usable display. I’ll get another teensy 3.6 and skip using 3.1 altogether.
I’ll also drop the color depth. I certainly don’t need 36bpp, and even 24bpp may be more than I need. I’ll try 16bpp too when I get a chance, especially as my target resolution for my new shirt design is 64x96 with 3x 64x32 P4 flexible panels given that it will fit.

As you point out, ESP32 with its two cores and better DMA capability (including RMT which may not be useful here,though), can refresh the panel full speed while calculating frames independently, which is very promising.
I already read that your current ESP32 is a bit alpha still, so I’m not sure if it will work for me yet, and I need to port my code/library to SmartMatrix first, but once that’s done, I’ll definitely look at moving back to ESP32, especially for its better debug/backtrace capability.

#4

Oh, thanks to your pointer to https://esp32.com/viewtopic.php?f=17&t=3188&sid=080935e1c3dd078cfe2c64d181b00e6d&start=40 in another thread, I also found this person who did https://github.com/mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA

GFX support already done with Panels, just what I needed :slight_smile:
Will need to look at this too.
Yeah for open source and people sharing and building on top of one another

#5

24, 36, 48 are the only options

GFX support already done with Panels, just what I needed

Sweet! Glad you found that

#6

Just to confirm, I plugged in the teensy 3.6 I just received, and I got over 120fps (limited to 120fps) on 64x64 without problems (as I expected). Now that I have 120fps, it indeed doesn’t look like crap anymore, even on my camera.

#7

About the bpp options. I know you’re a perfectionist and you actually worked towards more colors and color depth :wink:
That being said, as people are hitting limits with what their teensy can push, or building 128x128 panels which push the limit of what’s possible even with a teensy 3.6 while still keeping an acceptable refresh rate, I think supporting 16bpp RGB565 would make sense.
It would save RAM and give a higher refresh rate which is more important than more color depth if it’s at the expense of bad flickering.

Forgetting 128x128 for a second, even 64x64 had unacceptable flickering with a teensy 3.2. Maybe going down to 16bpp would have bumped up the refresh rate high enough that it would have been usable.

I don’t need this yet, but I can see how this would be useful for many uses cases that hit existing limits. I opened https://github.com/pixelmatix/SmartMatrix/issues/61 to track this.