Matrix Portal S3 wifi is sensitive to clock speed

[sharmstr]

I recently starting using your library over the ESP32-HUB75-MatrixPanel-DMA library. I have a very similar project to the tronbyt project. Everything is running great and you've done an excellent job.

Just as an fyi - The Adafruit Matrix Porta S3 wifi hates 20mhz clock speed. I dropped it down to 10mhz and it runs fine. But with the ESP32-HUB75-MatrixPanel-DMA I was able to request 25mhz, though it was actually 22mhz. I set your library to run 22mhz and it hasnt had a single wifi hiccup. Not sure if any of this really matters but thought you'd like to know.

[stuartparmenter]

Thanks, glad it is working well!

I'll do some more testing with the Matrix Portal S3 -- I haven't had any issues with it and 20mhz -- it could be the panel though. I also just added a 32mhz option, which I can get to usually work well on 1 64x64 panel but starts to fail if I chain more together. I may add some other clock rates, but they all end up as being divided by some rate and it's hard to get integer rates across all the various platforms.

[stuartparmenter]

Also, Do you have a good way to test the WiFi and 20mhz? Can put something together, or test in esphome more, but if you have something that would be great.

[sharmstr]

I should have been more clear. Sorry, its been a long day.

Im using "wifi" as a generic term. I have 15 devices running (not all purchased at the same time). At 20mhz my websocket connection is unstable and my image download speeds are slow or fail completely. Some of the cards have displays connected and some dont. It surprises me that the cards without displays have issues. In any case, at 10 or 22 mhz, my cards can run for days without a single http hiccup.

I dont have a proper test. I just watch the logs. I did some packet sniffing and at 20mhz there's a ton of retransmission requests. Its much quieter at 10 and 22 mhz.

[IngmarStein]

We've observed the same WiFi issue at 20 MHz also for other boards (Tronbyt S3 wide in my case). I haven't tried yet with 32 MHz, but if that's better, it probably has to do with harmonics. Thanks for mentioning this here!

[IngmarStein]

No luck with 32 MHz: the display was working, but the device was no longer able to connect to the WiFi - back to 8 MHz for now :/

[stuartparmenter]

Curious if you see any difference if you disable wifi power saving? esp_wifi_set_ps(WIFI_PS_NONE)

[IngmarStein]

I already had power saving disabled, but what really seems to make a difference is reducing the WiFi Tx power from the default 20 dBm to 11 dBm with esp_wifi_set_max_tx_power(44). With that, I'm able to establish a WiFi connection again, but now I'm suddenly facing severe IRAM pressure:

8 MHz:

I (26-01-19 14:15:52.010) main: Free heap before WS init: 8180652
I (26-01-19 14:15:52.016) main: Free PSRAM before WS init: 8168940
I (26-01-19 14:15:52.022) main: Free internal RAM before WS init: 36651

32 MHz:

I (26-01-19 14:17:12.533) main: Free heap before WS init: 8163120
I (26-01-19 14:17:12.538) main: Free PSRAM before WS init: 8160744
I (26-01-19 14:17:12.544) main: Free internal RAM before WS init: 8455

I'm curious why the clock speed makes such a difference? With that little IRAM, even websocket tasks fail to start.

[stuartparmenter]

I'm curious why the clock speed makes such a difference? With that little IRAM, even websocket tasks fail to start.

I assume you have bit depth default of 8? What do you have min refresh rate set to (60?)? 64x32?

Memory usage is a combo of clock speed, color depth, and refresh rate target.

Roughly:

=====================================================================================
BCM Timing Comparison
Panel: 64x32 x 1h x 1v
Bit depth: 8, Min refresh: 60 Hz, Four-scan: False, Double buffer: False
=====================================================================================
     Clock | lsbMsb | Trans/Row |    Refresh |   Desc Mem |    Row Buf |      Total
--------------------------------------------------------------------------------------------------------------
       8 MHz |      1 |        71 |    110.0 Hz |     12.2 KB |     16.0 KB |     28.2 KB
      10 MHz |      0 |       135 |     72.3 Hz |     24.0 KB |     16.0 KB |     40.0 KB
      16 MHz |      0 |       135 |    115.7 Hz |     24.0 KB |     16.0 KB |     40.0 KB
      20 MHz |      0 |       135 |    144.7 Hz |     24.0 KB |     16.0 KB |     40.0 KB
      25 MHz |      0 |       135 |    180.8 Hz |     24.0 KB |     16.0 KB |     40.0 KB
      32 MHz |      0 |       135 |    231.5 Hz |     24.0 KB |     16.0 KB |     40.0 KB
=====================================================================================

8MHz ends up using less memory because it uses fewer dma descriptors due to it automatically reducing color depth on the lowest bits to keep the refresh rate above 60 (it would be ~58 otherwise). If you were to bump min_refresh_rate above the rates in the chart above, it will force it to behave similarly to 8MHz and will end up using less memory. I'll think about how to make some of this more obvious

or if 128x64:

=============================================================================================================================
BCM Timing Comparison
Panel: 128x64 x 1h x 1v
Bit depth: 8, Min refresh: 60 Hz, Four-scan: False, Double buffer: False
=============================================================================================================================
     Clock | lsbMsb | Trans/Row |    Refresh |    Base Hz |   Desc Mem |    Row Buf |      Total
-----------------------------------------------------------------------------------------------------------------------------
       8 MHz |      3 |        23 |     84.9 Hz |     14.5 Hz |      7.1 KB |     64.0 KB |     71.1 KB
      10 MHz |      2 |        39 |     62.6 Hz |     18.1 Hz |     12.8 KB |     64.0 KB |     76.8 KB
      16 MHz |      2 |        39 |    100.2 Hz |     28.9 Hz |     12.8 KB |     64.0 KB |     76.8 KB
      20 MHz |      1 |        71 |     68.8 Hz |     36.2 Hz |     24.4 KB |     64.0 KB |     88.4 KB
      25 MHz |      1 |        71 |     86.0 Hz |     45.2 Hz |     24.4 KB |     64.0 KB |     88.4 KB
      32 MHz |      1 |        71 |    110.0 Hz |     57.9 Hz |     24.4 KB |     64.0 KB |     88.4 KB
=============================================================================================================================

[IngmarStein]

My memory measurements above were done with these parameters:

• resolution: 128x64
• double buffering: true
• min refresh rate: 60
• bit depth: 8

The only difference was the clock speed (8 MHz vs 32 Mhz) which resulted in an increase of 28196 bytes.

[stuartparmenter]

Try bumping min_refresh_rate to 120 and see what that looks like.

I'll do some more detailed memory measuring and build a more robust calculator when I get a chance

[IngmarStein]

min_refresh_rate = 120 results in a usable amount of free memory. Now I'm on a quest to free up memory to make it work with lsbMsbTransitionBit=1 :)

I (26-01-19 15:13:49.167) GdmaDma: Clock: 32 MHz
I (26-01-19 15:13:49.171) GdmaDma: Buffer transmission time: 4.00 µs (128 pixels @ 32000000 Hz)
I (26-01-19 15:13:49.180) GdmaDma: lsbMsbTransitionBit=2 achieves 200 Hz (target 120 Hz)
W (26-01-19 15:13:49.187) GdmaDma: Using lsbMsbTransitionBit=2, lower 3 bits show once (reduced color depth for speed)
…
I (26-01-19 15:13:59.454) main: Free heap before WS init: 8178080
I (26-01-19 15:13:59.460) main: Free PSRAM before WS init: 8168940
I (26-01-19 15:13:59.466) main: Free internal RAM before WS init: 24691

[sharmstr]

I think I've found the sweet spot. 32mhz, 8-bit, 90 refresh

# ------------------------------------------------------------------
# Hardware Components (HUB75 Matrix)
# ------------------------------------------------------------------
CONFIG_HUB75_BOARD_ADAFRUIT_MATRIX_PORTAL_S3=y
CONFIG_HUB75_PANEL_WIDTH=64
CONFIG_HUB75_PANEL_HEIGHT=64
CONFIG_HUB75_CLK_16MHZ=n  // downloads too slow, unstable
CONFIG_HUB75_CLK_20MHZ=n  // downloads too slow, unstable
CONFIG_HUB75_CLK_32MHZ=y  // fast, stable downloads
CONFIG_HUB75_LATCH_BLANKING=1
CONFIG_HUB75_BRIGHTNESS=127
CONFIG_HUB75_DOUBLE_BUFFER=y
CONFIG_HUB75_DRIVER_FM6126A=y
#CONFIG_DEPTH_10=y  // Ran fine with 10mhz, but lsbMsbTransitionBit = 3
#CONFIG_HUB75_BIT_DEPTH=10
CONFIG_HUB75_MIN_REFRESH_RATE=90  // 120 ran fine, but lsbMsbTransitionBit = 1

[sharmstr]

ooof. The latest update has killed the colors. Everything is washed out and my dark areas have greens, yellows and purples in them. I have a status image that has a solid purple background that's now pink.

_matrix->fill(0, 0, CONFIG_HUB75_PANEL_WIDTH, CONFIG_HUB75_PANEL_HEIGHT, 75, 0, 130);

This happens at all brightness levels. I only updated the library, no other changes.

[sharmstr]

FWIW. Any combo of 10mhz (8 or 10 bit) looks washed out. I can fix most of the color issues (purple looking pink, image washed out) with 32mhz and double buffering disabled. I still get strange colors in dark areas.

In summary, in order to use the config I listed above with the new updates, I had to disable double buffering.

[sharmstr]

I finally received larger versions of the webp's Im displaying. The strange colors in the dark areas are in the original file. So looks like your recent changes are working like they should. You'll see faint green in the dark area to the right of her head and faint red and green to the left. Older versions of your library didnt have this detail so I thought it was noise. Sorry again.

[stuartparmenter]

Great, thank you for testing. There were a few real (subtle) issues in the last release but think things look pretty good now. Appreciate you flagging and helping me test!

[IngmarStein]

@sharmstr maybe there are some artifacts after all. @tavdog also noticed this in dark areas on a Tidbyt Gen1 (ESP32, I2S). I don't see them myself on Tronbyt S3 devices (ESP32-S3, GDMA):

[IngmarStein]

I forgot to mention: using esp-hub75 0.3.2

[stuartparmenter]

Thanks, will review the two -- their implementations should be nearly identical aside from different max clock speeds (which could impact color precision...) and do some further comparison between them

[stuartparmenter]

On WiFi / clock speed issues, I've put together #79 and am curious if it might help. If any of you are able to build against this branch and could let me know if any of these options work better that would be awesome

[sharmstr]

Here you go....

At 32mhz....
I (810) GdmaDma: LCD clock: PLL_F160M / 5 = 32.00 MHz
Size: 111050 downloaded in 487 ms
Size: 2452 downloaded in 74 ms

At 23mhz. Still stable, but download time takes a hit. (note: This is what I had with mrcodetastic library)
I (814) GdmaDma: Clock: 22.86 MHz (requested 23 MHz)
Size: 111050 downloaded in 14902 ms
Size: 2452 downloaded in 444 ms

At 20mhz. Unstable, constant disconnects, downloads speed is brutal
Size: 111050 downloaded in 20584 ms
Size: 2452 downloaded in 1517 ms

[stuartparmenter]

Thanks, I'll probably add these then, but will also see if I can do anything else to avoid the problem in the first place.