Closed NPohl closed 5 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.
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.
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.
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 @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.
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
@WarC0zes is there any guide to build image from ini? i am adanced user, but i dont know about these things. thanks
@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
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
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.
I did this DIY and it has worked well since then.
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).
I'm guessing this is not shielding but antenna deflector gain.
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.
Is this problem resolved now?
Perform all steps below and tick them with [x]
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
For me this results a large variance in ping times, e.g.
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:
This results in a quite reliable (=it connects reliably) and fast WiFi connection:
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
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.