I2S and WiFi interference

[vortigont]

Hi all,
inspired by #256 (but not necessary related)
Has anyone ever noticed generic WiFi issues with esp32 when I2S engine running at clock speed 10 and specially 20 MHz?
I remember facing this severely sometime ago. With running i2s a simple pinging board's IP becomes spiky with a huge jitter. For quite a while I was even thinking that some of my boards are faulty. Than using Hallard's shield made life a little bit easier, so I forgot about it. Currently I do not have any LED boards at hand, so can't test or confirm it. Just want it to be here to be confirmed or dis-proofed by others.
Maybe tweaking clock speed to something other than multipliers of 10 MHz could make a difference.

Cheers!
cc @mrfaptastic @solhuebner

[mrcodetastic]

Interesting. So you're thinking this isn't a SoC DMA / silicon issue causing internal bandwidth contention with the WIFI stack, but actually RF noise generated by GPIO output possibly impacting WiFi performance?

So, potentially something to do with harmonics?

[board707]

So you're thinking this isn't a SoC DMA / silicon issue causing internal bandwidth contention with the WIFI stack, but actually RF noise generated by GPIO output possibly impacting WiFi performance?

I don’t think that this is RF noise, since on the other lib the output to the matrix does not interfere with Wi-Fi.
I just checked that on PxMatrix I can stream lowres video to 64x32 panel via ESP32 WiFi with 25 fps with only minor artifacts

[vortigont]

yep, might be that way. First I suspected that something is wrong here when working with my testbed. Periodic UI updates were quite unstable, sometime better in AP mode, sometimes not. Do not remember if it was before we dropped clock rates other than 10/20 MHz or later. But it definitely worth a closer look next time.

[vortigont]

Found similar issue, just leave it here for crossreference espressif/arduino-esp32#5834

[ergindemir]

What kind of devkit/pcb are you using? Most devkits are poorly designed with signal traces on the bottom of the pcb.

[vortigont]

It was Wemos D1 esp32 with and without Hallard's shield.
Boards are OK, since I've used it before for other projects with no similar issues.

[ergindemir]

Ideally all signal traces should be on the top with pure ground on the bottom plane. No gpio pins next to the antenna. In addition the board should come with a proper regulator, high output capacitor and decoupling capacitor next to the module. Finally, you should check if your board uses a genuine or knock off wroom module. If you can eliminate all these factors you may suspect that the 12th or 24th harmonic of the i2s signal causes the issue. From my experience devkit v1 module works fine despite knock off module, low output cap, few signal traces on the bottom and few pins next to the antenna. Another devkit with 38 pin which suffers from all causes above has severe wifi issues.

[xavirg]

I'm facing this same issue with an Adafruit Matrix Portal S3 board.

With the display initialized, wifi is unstable and I get timeouts on my websockets clients or my HTTP client, both fail from time to time and then reconnect.

If I don't init the display, connections run smooth without a single failure.

This has been driving me nuts. I even tried with different power supplies, cables and even changed the AP 😤

[xavirg]

Isn't the clock speed already set to 8Mhz by default?

Gonna test my board manually setting the speeds as I'm waiting for another board. I'll come back to you.

HUB75_I2S_CFG mxconfig(64, 32, 1, pins);
mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_8M;

[xavirg]

Seems like setting the clock to 20MHz solves my problem 🚀 . With HUB75_I2S_CFG::HZ_20M;, everything works as expected:

I (5254) I2S-DMA: Free heap: 278828
I (5264) I2S-DMA: Free SPIRAM: 0
I (5264) I2S-DMA: allocating rowBitStructs with pixel_color_depth_bits of 8
I (5274) I2S-DMA: Allocating 16384 bytes memory for DMA BCM framebuffer(s).
I (5274) I2S-DMA: Minimum visual refresh rate (scan rate from panel top to bottom) requested: 60 Hz
W (5284) I2S-DMA: lsbMsbTransitionBit of 0 gives 76 Hz refresh rate.
I (5294) I2S-DMA: DMA has pixel_color_depth_bits of 8
I (5294) I2S-DMA: Recalculated number of DMA descriptors per row: 128
I (5304) I2S-DMA: 2048 DMA descriptors linked to buffer data.
I (5304) S3: Clock divider is 7
I (5314) I2S-DMA: DMA setup completed
I (1754) main_task: Returned from app_main()
I (8894) websocket: got data (124 bytes)
I (8894) draw: drawing webp (1 frames)
I (8904) draw: finished
I (28764) websocket: got data (3406 bytes)
I (28764) draw: drawing webp (12 frames)
I (29324) draw: finished
I (48964) websocket: got data (20896 bytes)
I (48974) draw: drawing webp (200 frames)
I (68874) draw: finished
I (68904) websocket: got data (124 bytes)
I (68904) draw: drawing webp (1 frames)
I (68914) draw: finished

However, if I set it to 8MHz or keep it unsetted I get two more warnings about lsbMsbTransitionBit. Then the wifi connection does some negotiations and the websocket client starts to fail:

I (1694) I2S-DMA: Free heap: 278824
I (1704) I2S-DMA: Free SPIRAM: 0
I (1704) I2S-DMA: allocating rowBitStructs with pixel_color_depth_bits of 8
I (1714) I2S-DMA: Allocating 16384 bytes memory for DMA BCM framebuffer(s).
I (1714) I2S-DMA: Minimum visual refresh rate (scan rate from panel top to bottom) requested: 60 Hz
W (1724) I2S-DMA: lsbMsbTransitionBit of 0 gives 30 Hz refresh rate.
W (1734) I2S-DMA: lsbMsbTransitionBit of 1 gives 61 Hz refresh rate.
W (1734) I2S-DMA: lsbMsbTransitionBit of 1 used to achieve refresh rate of 60 Hz. Percieved colour depth to the eye may be reduced.
I (1754) I2S-DMA: DMA has pixel_color_depth_bits of 7
I (1754) I2S-DMA: Recalculated number of DMA descriptors per row: 64
I (1764) I2S-DMA: 1024 DMA descriptors linked to buffer data.
I (1764) S3: Clock divider is 16
I (1774) I2S-DMA: DMA setup completed
I (1784) main_task: Returned from app_main()
I (2264) wifi:<ba-add>idx:1 (ifx:0, 70:3a:cb:29:e9:27), tid:0, ssn:1, winSize:64
I (4794) wifi:<ba-del>idx:1, tid:0
I (5294) wifi:<ba-add>idx:1 (ifx:0, 70:3a:cb:29:e9:27), tid:0, ssn:3, winSize:64
I (6324) wifi:<ba-del>idx:1, tid:0
I (6974) wifi:<ba-add>idx:1 (ifx:0, 70:3a:cb:29:e9:27), tid:0, ssn:4, winSize:64
I (14044) wifi:<ba-del>idx:1, tid:0
I (14144) wifi:<ba-add>idx:1 (ifx:0, 70:3a:cb:29:e9:27), tid:0, ssn:7, winSize:64
I (15034) wifi:<ba-del>idx:1, tid:0
I (15064) wifi:<ba-add>idx:1 (ifx:0, 70:3a:cb:29:e9:27), tid:0, ssn:9, winSize:64
E (34634) transport_ws: Error read data
E (34634) transport_ws: Error reading payload data
I (44974) websocket: got data (109 bytes)
E (44974) draw: failed to create WebP decoder
W (44994) transport_ws: esp_transport_ws_poll_connection_closed: unexpected data readable on socket=54
W (44994) websocket_client: Connection terminated while waiting for clean TCP close

[JetForMe]

I have the same problem with the Adafruit MatrixPortal S3. I've tried 8, 15, and 20 MHz without success.

[w531t4]

same

[mrcodetastic]

Looks like a common problem with this board.

Probably the way they've created the PCB there's some resonance or noise.

[JetForMe]

Not sure if I should start a new discussion or continue here. But I tried my same code using Protomatter instead of this library, and WiFi stays reliable. I'm not sure why, but on the Adafruit MatrixPortal S3 using this library, I can't get any speed from 1 MHz to 20 MHz to not kill wifi.

[JetForMe]

Okay, after days, and many hours of experimenting, I'm fairly confident that this is an issue with the WROOM-1 module, and not likely to be any kind of processor resource contention issue. I've got it working fairly reliably with UM Pro S3 and Feather S3 modules, with both on-board chip antenna and U.FL antenna.

When I first started trying the other boards, I was still experiencing the problems. Thinking it must be resource contention, I wrote my own Web Sockets client to sit atop AsyncTCP, hoping that would improve the CPU core utilization. Things started to work, so I tried it on the WROOM-1 board again, and it failed as it always does. I went back to the UM boards, and it continues to work.

I'm unable to determine if there’s still some interference, but it seems to be performing adequately for my needs, for now. I have yet to see if it will work in the final deployment environment, but I have no real reason to believe it won’t.

[xavirg]

I've got it working fairly reliably with UM Pro S3 and Feather S3 modules, with both on-board chip antenna and U.FL antenna.

Which CPU do they use? I also see they both have 8MB of extra PSRAM.

The MatrixPortal S3 only has 2MB of memory, which results in having about 200kB available at runtime.

[victorhooi]

I'm also trying to do some experiments with HUB75 panels ATM, and trying to pick the right controller.

The Adafruit Matrix Portal S3 seemed like a good option - however, then I read here that there might be wifi RF/EMI issues with it - and it seems like the SRAM (2MB) amount is too low?

Is the memory amount not enough? And did anybody definitive prove it was a wifi EMI issue? (I think I have a SDR around somewhere - and I'm happy to order a Adafruit Matrix Portal S3, and do some tests, if that would help at all? Definitely not an RF or embeeded expert/guru though - but happy to try to do any tests that people think might help here).

Apollo Automation also has their new M-1 LED panel and controller - which also seems to be an ESP32-S3 - not sure if that would have similar issues?

Or are there alternative HUB75 controllers, or ESP32-to-HUB75 breakout boards that people recommend?

[mrcodetastic]

Do you only want to drive a LED panel? If so, might be worth looking at using a WF2: https://github.com/mrcodetastic/HD-WF1-WF2-LED-MatrixPanel-DMA

Note: If you use one of these devices you won't get access to any of the other GPIOs given it's a board designed only for driving an LED panel.

[xavirg]

The Adafruit Matrix Portal S3 seemed like a good option - however, then I read here that there might be wifi RF/EMI issues with it - and it seems like the SRAM (2MB) amount is too low?

Is the memory amount not enough?

Memory is sufficient. I had the wifi issue just starting my program by initializing wifi and then initializing the display, nothing else.