Flakey WiFi on Sunton ESP32-8048S050C

NPohl commented 11 months ago

Perform all steps below and tick them with [x]

[x] Check the related part of the Documentation
[x] Update openHASP to the latest version
[x] Reproduce the issue and describe all steps

Describe the bug

WiFi is flakey for me on a Sunton ESP32-8048S050C board. It seems a bit random, sometimes it takes very long to connect or does not connect at all, sometimes it more or less works. Pinging the boards also shows large variance in ping times. Using the boards from HA is also not very reliable, as the network connection seems not very stable.

To Reproduce

Flash nightly from https://nightly.openhasp.com/ on a ESP32-8048S050C.
Set up WiFi (as described here)
Wait for the board to connect (sometimes this already fails or takes very long)
If it connects, ping the board on the IP it shows

For me this results a large variance in ping times, e.g.

C:\>ping -t 192.168.46.134

Pinging 192.168.46.134 with 32 bytes of data:
Reply from 192.168.46.134: bytes=32 time=455ms TTL=255
Reply from 192.168.46.134: bytes=32 time=41ms TTL=255
Reply from 192.168.46.134: bytes=32 time=58ms TTL=255
Reply from 192.168.46.134: bytes=32 time=39ms TTL=255
Reply from 192.168.46.134: bytes=32 time=47ms TTL=255
Reply from 192.168.46.134: bytes=32 time=219ms TTL=255
Reply from 192.168.46.134: bytes=32 time=322ms TTL=255
Reply from 192.168.46.134: bytes=32 time=21ms TTL=255
Reply from 192.168.46.134: bytes=32 time=15ms TTL=255
Reply from 192.168.46.134: bytes=32 time=36ms TTL=255
Reply from 192.168.46.134: bytes=32 time=100ms TTL=255
Reply from 192.168.46.134: bytes=32 time=27ms TTL=255
Reply from 192.168.46.134: bytes=32 time=50ms TTL=255
Reply from 192.168.46.134: bytes=32 time=100ms TTL=255
Reply from 192.168.46.134: bytes=32 time=9ms TTL=255
Reply from 192.168.46.134: bytes=32 time=49ms TTL=255
Request timed out.
Reply from 192.168.46.134: bytes=32 time=613ms TTL=255
Reply from 192.168.46.134: bytes=32 time=109ms TTL=255
Reply from 192.168.46.134: bytes=32 time=220ms TTL=255
Reply from 192.168.46.134: bytes=32 time=35ms TTL=255
Reply from 192.168.46.134: bytes=32 time=57ms TTL=255
Reply from 192.168.46.134: bytes=32 time=44ms TTL=255

Expected behavior

To ensure, this is not due to faulty hardware or bad WiFi reception, I wrote the following simple WiFi program in PlatformIO and flashed it to the board:

#include <Arduino.h>
#include <WiFi.h>

#include "config.h"

void setup() {
  Serial.begin(115200);

  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  Serial.println("\nConnecting to WiFi Network ..");

    while(WiFi.status() != WL_CONNECTED){
        Serial.print(".");
        delay(100);
    }

    Serial.println("\nConnected to the WiFi network");
    Serial.print("Local ESP32 IP: ");
    Serial.println(WiFi.localIP());

    WiFi.setSleep(WIFI_PS_NONE);
}

void loop() {
  Serial.print(".");
  delay(1000);
}

This results in a quite reliable (=it connects reliably) and fast WiFi connection:

C:\>ping -t 192.168.46.134

Pinging 192.168.46.134 with 32 bytes of data:
Reply from 192.168.46.134: bytes=32 time=7ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=7ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255
Reply from 192.168.46.134: bytes=32 time=9ms TTL=255
Reply from 192.168.46.134: bytes=32 time=2ms TTL=255
Reply from 192.168.46.134: bytes=32 time=3ms TTL=255

Side note: It looks the same for a WT32-SC01 display I've lying around here.

Further investigation

I downloaded the latest version of the openhasp code from github to see if I can find a reason when/why the WiFi gets flaky. What I've found so far is that the WiFi starts getting flaky once

haspTft.init(tft_width, tft_height);
in gui_start_tft()
    gui_init_tft()
    guiSetup()
    setup()

is called.

Looking also at the sample code for the board, I've started playing with the parameters provided to Arduino_RGBPanel_Mod for the display. I've found that WiFi is stable for TFT_PREFER_SPEED >= 22MHz, but the display unfortunately starts to show horizontal sync issues when going above 16MHz...

Since it looks like the specs for the display specify 23-27MHz for the pixel clock, my hypothesis is that the ESP32-S3 isn't able to write out the data correctly when set to such high clocks.

When setting the pixel clock to a lower value on the other hand, my suspicion is that this blocks PSRAM longer and therefore starts to affect WiFi. See this FAQ entry for more on this.

As a potential solution I've tried to prevent WiFi from using PSRAM, but was not successful so far. I'm also not quite sure how I can change the config settings for ESP-IDF with the code compiled via PlatformIO... so I've might already failed there.

So I've thought I log what I have found so far in the hope this helps to get the issue fixed.

wladkolc commented 11 months ago

Hi, same problem here with ESP32-8048S050C. I have tried latest openhasp with ESP32-3248S035 and after this problem i have ordered 8048S050C because i thought it was problem with missing PSRAM. Both devices are not usable.

ncot-tech commented 11 months ago

I also have the same issue with an ESP32-80482070C. It was working fine then I changed the Theme to something other than "Hasp Dark" (theme 3) and the wifi started dropping out and the web interface became unreachable.

I have, after about 20 minutes of trying using a combination of the web interface and Telnet managed to set the config back to Hasp Dark and it now seems to be working normally again.