Need Build Advice on ESP32 Project (Not ESPEasy)

[ThomasB]

I've been working on a ESP32 based FM transmitter project for several weeks. It uses Arduino Libraries and is built using the Platformio IDE.
.

ESP32 based FM Radio

pcb_RevA1_800.jpg (174.5 KiB) Viewed 7891 times

.
I'm experiencing a Wifi issue involving random WebSocket disconnects. That is to say, browsers (FF, Edge, Chrome) lose connectivity after awhile. Sometimes hours later, sometimes in a matter of minutes. Longest continuous run time has been 13 hours. Refreshing the browser re-establishes the connection.

No reboots are occurring. The device continues to work normally during the browser disconnect (browser is used to monitor some real-time status data).

The disconnect isn't due to inactive connections; Websocket data is being sent from the ESP32 every second. RSSI is strong (about -50dBm) since the Access Point is in the same room. Clean power: Linear Vregs with large value stability caps and plenty of decoupling caps on 5V and 3.3V buses.

I've exhausted all hardware related fixes and I now suspect it may be Arduino library related. Especially given all the past WiFi troubles ESPEasy has experienced, where some fixes involved the compile build choices.

So I thought I ask here. Is there a "golden" ESP32 related Arduino release that I should be using in my Platformio builds? Or specific WiFi libraries? That is, those that are known to have the best WiFi stability. In case it matters, the project #includes are ESPAsyncWebServer.h, DNSServer.h, ESPmDNS.h, and WiFi.h.

Would be great to get this solved. Having to refresh the browser to recover from the disconnect is working, but reduces the joy in using an otherwise cool device.

- Thomas

[TD-er]

Are you using some kind of login?
Could it be a session that expires?

[ThomasB]

@TD-er, VERY glad see you jump in.

Yes, I am using login on the web connection. I can also connect without login; I will try this out tonight.

It is weird that the disconnects occur randomly. Seems like a session timeout would be the same each time. But I'm game to try nearly anything.

BTW, suggestions like checking for session timeouts are the kind of ideas I need. So please keep them coming.

EDIT: Tested without login, disconnected in 4 hours 36 minutes.Any other advice?


- Thomas

[TD-er]

Set AP to fixed WiFi channel.
Try to connect using B/G mode (and make sure to allow it on the AP)
Use channel 1, 6 or 11 as those are the only ones that do not have overlap from other channels when using max. channel bandwidth. The ESP will not use the max. channel width, but other devices might and when using channels other than the ones I mentioned, you may have interference from twice as many devices around you.
Have a good look at those turkeys near you, they might take revenge by having a node with them running the de-auth firmware

[ThomasB]

Thanks for the tips. I'll try them now. For the test I've set my router to CH 11 / 54mbps, so no code changes will be needed.

I considered the turkeys were involved, but I haven't seen them for several weeks. But they are clever and may have hidden the de-auth node in the shrubs.

- Thomas

[ThomasB]

Ran with the CH 11 / 54mbps settings. At 13 hrs, 56 minutes a WebSocket disconnect occurred. Beat my previous record that was about 11 hrs, but still no joy.

BTW, I operate the device in STA mode. But also confirmed the issue occurs in AP mode.

Another observation is that if I have multiple browsers connected they all disconnect at the exact same time. Could be an important clue, or maybe not.

In case I've done a bad job of explaining the problem, the issue is that the browser stops updating the data fields on my Web UI. These values are provided by my ESP32 WebSocket server.

One of the data fields that is displayed is Available Memory. Updated every two seconds, typically ~200KB, no leaks.

When the disconnect occurs a onWsEvent callback receives a WS_EVT_DISCONNECT event type. I normally only see this event when a browser is deliberately closed or pointed to a different URL. That's what is expected to happen. But randomly the WS_EVT_DISCONNECT event occurs too, which is the mystery I eagerly wish to solve.

- Thomas

[TD-er]

The access point may disconnect any/all clients at will for several reasons:
- Too many errors or resend requests
- Too many clients connected (or open/not closed sessions)
- Initiate a channel change

And some other reasons.
So you should "subscribe" to WiFi events and try to check what kind of WiFi event you get.
If you get disconnected, you should try to reconnect.
If reconnect fails (e.g. immediately get disconnected) you can try to turn WiFi.mode(WIFI_OFF) and turn it on again and reconnect.

[ThomasB]

Thanks again for the advice. I suppose the most practical solution is to have the browser automatically refresh when a disconnect occurs.

More observations that may be relevant:
My device supports MQTT too. When the WebSocket disconnects, MQTT is unaffected. That is to say, my serial logs show that the MQTT broker remains connected. The serial logs only report the WebSocket disconnect. And before you ask, disabling MQTT does not fix the problem.

And the WiFi Router remains connected. The disconnect applies only to the WebSocket interface. That is to say, the ESP32 remains in STA mode.

So you should "subscribe" to WiFi events and try to check what kind of WiFi event you get.

I would love to do that. Currently I am relying on the onWsEvent callback. I thought it would report those details. But it's no help, only tells me that the client has disconnected.

My friend Google didn't help me find an example; can you suggest any code examples in ESPEasy that I can use as inspiration to do the WiFi event "subscribe" trickery? For sure, knowing why it disconnected may help direct me to the best solution.

- Thomas

[TD-er]

Do you have WiFi auto reconnect enabled?
Or better, have you explicitly disabled this as it is enabled by default?

[ThomasB]

Do you have WiFi auto reconnect enabled?
Or better, have you explicitly disabled this as it is enabled by default?

I'm not positive what you mean. Are referring to the client's (PC with browser) auto reconnect for AP Hot Spots? Or something else?

Maybe you mean WiFi.setAutoReconnect()? I don't use that function. Should I?

FWIW, my ESP32 device is intended to operate in STA mode, so it is not using AP mode. However, it temporarily provides an AP connection (same as ESPEasy) when it is used for setting up a new install. After WiFi credentials are entered the AP mode is not used. That is to say, after WiFi is configured the device is rebooted and uses STA WiFi mode.

During STA mode the WiFi status is monitored (e.g. WiFi.status() != WL_CONNECTED). A routine reconnects if the WiFi status reports it is not connected. My Serial log would report when this occurs; but it never happens. That means that WiFi remains connected when my WebSocket becomes disconnected. Or so it seems.

Edit 1: I added the code snippet shown below to my connect function, after WiFi.begin(). Currently testing it to see how it affects the WebSocket issue:

Code: Select all

WiFi.setAutoReconnect(false);
WiFi.persistent(false);

Don't know if that's something you intended for me to try. But it's my best guess at what to do next.

Edit 2: Now next day, the new code did not change the behavior. The WebSocket disconnected after 10 hrs 57 mins, but WiFi STA connection was still OK. Did my usual browser refresh and the data provided by WebSockets was working again.

- Thomas

[ThomasB]

A month later: I didn't solve the random Websocket disconnect issue. Although it is a nuisance (at least in my mind), it does not affect operation of the radio transmitter. So I decided to ignore the bug for now and instead concentrate on finishing the project.

In case any of you are pixel display hobbyist, then perhaps my "PixelRadio" project will interest you. It doesn't use ESPEasy but it is based on a ESP32. All the details are here:
https://github.com/thomastech/PixelRadio

RadioLogo300.gif (4.01 KiB) Viewed 6434 times

- Thomas