Flakey WiFi on Sunton ESP32-8048S050C

[NPohl]

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

1. Flash nightly from https://nightly.openhasp.com/ on a ESP32-8048S050C.
2. Set up WiFi (as described here)
3. Wait for the board to connect (sometimes this already fails or takes very long)
4. 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]

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]

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.

[WarC0zes]

Hi, I noticed wifi disconnections and latency in actions with home assistant on the ESP32-80482070C. The web server is a little slow to load. I'm using version 0.7.0-rc9 b7283c9. I've an elecrow 8048C070 (elecrow-s3-8048C070_4MB), and it works very well, no wifi problems.

[wladkolc]

it look unstable and unusable for now. it's sad that I didn't know about Elcrow devices before buying Sunton. waste of money.

[WarC0zes]

Hi @NPohl, look at this post on the elecrow WZ8048C070 which is a similar card but with 4MB flash. The author had problems with WiFi and used the LovyanGFX library to solve the problem. https://github.com/HASwitchPlate/openHASP/discussions/559

To know if it can work with the ESP32-8048S050C or ESP32-8048S070C.

[WarC0zes]

it look unstable and unusable for now. it's sad that I didn't know about Elcrow devices before buying Sunton. waste of money.

Hi, elecrow 8048C070 isn't supported yet. You have to compile the firmware with the .ini from this post https://github.com/HASwitchPlate/openHASP/discussions/559

[wladkolc]

@WarC0zes is there any guide to build image from ini? i am adanced user, but i dont know about these things. thanks

[WarC0zes]

@WarC0zes is there any guide to build image from ini? i am adanced user, but i dont know about these things. thanks

@wladkolc you have the explanation in the doc, I used gitpod to compile the firmware. https://www.openhasp.com/0.7.0/firmware/compiling/gitpod/ or I made a tutorial to compile the firmware for the elecrow 7 inch model on the home assistant English forum. https://community.home-assistant.io/t/5inch-display-ili6122-ili5960-need-help-to-add-it-to-esphome/624278/11?u=warc0zes

[WarC0zes]

Hi, I found a solution to make the Sunton 7 inch work properly. The cause may be due to the esp32 chipset not being well protected from interference. With just an aluminum tab attaching part of the esp32 chipset, fixes WiFi cutoff issues.

https://github.com/HASwitchPlate/openHASP/discussions/413#discussioncomment-7981610

C:\Users\xxxx>ping -n 10 192.168.1.xx

Envoi d’une requête 'Ping'  192.168.1.xx avec 32 octets de données :
Réponse de 192.168.1.xx : octets=32 temps=1 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=2 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=1 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=5 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=3 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=2 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=3 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=3 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=3 ms TTL=255
Réponse de 192.168.1.xx : octets=32 temps=1 ms TTL=255

Statistiques Ping pour 192.168.1.xx:
    Paquets : envoyés = 10, reçus = 10, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
    Minimum = 1ms, Maximum = 5ms, Moyenne = 2ms

[romainrossi]

Same issue on Sunton ESP32-8048S043 with version 0.7.0-rc10 fb2bebf (from nightly). I noticed the Wifi connection is better when I put one finger near the ESP32 antenna (not two fingers...). The ping improve and the card become usable again. Seems like a perturbation indeed.

[WarC0zes]

#413 (reply in thread)

I did this DIY and it has worked well since then.

[romainrossi]

Thanks for the tip @WarC0zes. I guess I just have to buy cat food (and a cat) :-) I tried and it work (the ping is improved). This is counter-intuitive as shielding the antenna is (normally) not a thing to do... However, for now I am using your hack. I will try to investigate further if I am able to find the source of the perturbation (shielding this part should be better).

[darkman7hr]

I'm guessing this is not shielding but antenna deflector gain.

[romainrossi]

The aluminum tab hack was not so successful after longer tests on my board.

So, I tested other ideas, and I got good results by changing the frequency of the TFT.

In the file user_setups/esp32s3/sunton-esp32-s3-tft.ini, in the environment corresponding to my board : [env:sunton-8048s043c_16MB] I changed the variable TFT_PREFER_SPEED to 13900000 (from the default value of 14000000). It improved the wifi connection a LOT. I tested multiple values but this one is the best.

[fvanroie]

Is this problem resolved now?