ESP32 WiFi Superstitions

Having a protocol for working with a black box is fine. The problem is how bad a lot of people are at differentiating between superstition, a black box, and a process with a well understood mechanism.

Same as Cargo Cult programming: https://en.wikipedia.org/wiki/Cargo_cult_programming

I’ve been referring to this kind of belief as a ‘pigeon religion.’ This one time an operator has a problem (it’s an e-stop that hasn’t been reset) and they ‘fixed it’ by switching the system into test mode and back, then pressing the e-stop reset three times. So they tell all their friends.

Next time that doesn’t work (the e-stop button is still pressed in) but someone tries switching the system into test mode and back twice, slamming the control cabinet door, pressing and releasing the e-stop button three times, then pressing the e-stop reset button three times. They report their findings on the new standard procedure…

And so on.

Is wood glue really not stronger than wood?

I used to say things like that, but come on: Arduino is targeted at hobbyists. More specifically, it's targeted at hobbyists who don't want to spend too much time learning hardware. If they did, they would be using a "bare" microcontroller better suited for their needs and costing one tenth the price. But they're not interested in microcontroller programming, they just want to get their art project done.

It's the same thing that happened with computers. Billions of people use them, but most just want to access Facebook or use MS Word, not learn OS internals. It's a different world from where we used to be 30-40 years ago, and that's fine. We design simpler, more intuitive products for them.

If a product meant for that group can't be used effectively by the target audience, I think the fault is with the designer, not with the user.

> It disables the radio in between AP beacons, so unless there's a bug in the implementation it should have no noticeable impact to a quiet WiFi station other than saving a lot of power.

Seems safe, but it probably depends on the clock being accurate, so it can wake up on time for the next beacon, and the clock frequency is likely sensitive to temperature and therefore power usage.

If you're plugged into a wall wart, chances are the power savings aren't going to be too much; if it helps reliability (which should be easy to confirm), then it's likely worth paying a cent or two more a month. It's different if you're running from battery, though.

To be fair, the API people typically use in hobbyist contexts is literally a single call to 'WiFi.begin(ssid, password)'. There's not exactly any obvious room for error here, and any details which may or may not have been implemented incorrectly are so deep inside abstraction layers as to be inaccessible. There's little apparent room for making the code more robust (other than "workarounds" like application level health checks + reboot on error), because everything is supposed to have been taken care of by the abstraction.

If I can disable PM and then my ESP stops disconnecting from WiFi, I'm happy. There's not much more I can do without re-implementing what 'WiFi.begin()' does myself, and I usually have better things to do with my time.

> It disables the radio in between AP beacons, so unless there's a bug in the implementation it should have no noticeable impact to a quiet WiFi station other than saving a lot of power.

A) this increases ripple voltage which eventually impacts RX noise floor. As long as you have enough headroom at the input to your regulator power saving is great, but eventually having a more consistent load becomes the limiting factor for many devices.

B) drastically increases typical latency - not an issue for all applications, but the ESP-IDF network stack has a Nagler that can't always cleanly be disabled and tends to write each little bit of the next layer to the TCP socket.

Good highlight. In commercial deployments absolutely, I'd even recommend going as far as hiding any SSID you don't explicitly want people to be manually clicking on with their own devices (i.e. only guest and/or byod should be visible). Not because of security (as the conversation often tangents into) but because the support tickets for "I can't connect to <wrong SSID>" just go away and it clutters screens less as you say.

For home it has its ups and downs depending how much the user cares about understanding Wi-Fi as part of their project vs just doing the minimum to make their project work. If you've already got a Wi-Fi scanner app you're well acquainted with reading (or are willing to spend a short bit of time reading about how to use one to troubleshoot an issue or select the best covering AP at a location) on one of your devices then you're probably the right crowd to hide the SSID at home as well.

I haven't had an Android device for a number of years now but my guess is "no" from the device side unless you're going to go make your own custom firmware with Wi-Fi settings tweaked or newer Wi-Fi drivers which handle roaming better.

If your router and device support 802.11 k/v/r it can help, most likely the AP does unless it's particularly ancient and Android has supported all of these since 8.0. Ironically, lowering the AP's power can help too (it'll cause the client to see the farther AP as weaker sooner) but obviously that lowers overall coverage at the same time... so it's a tradeoff unless you're willing to deploy more APs to make up for the lower power. Make sure you're restricting advertised rates from your AP to not include the slowest/oldest standards as well. That'll make the client less able to hold on as the connection gets weaker and weaker. Like the power recommendation, this means at the fringes of your coverage you'll get "no connection" rather than "a bad connection" but it'll make the overall airspace healthier.

If nothing else works and you can't fix the client because you lack full control (or a reasonable way to update it) then you can still try falling back to steering clients via hints from the AP (if it supports it) just keep in mind it also may not work and also may cause problems with other devices which were working fine. Or you may get lucky, worth a shot if you've tried everything else first.

As a note: My experience comes from designing and fixing enterprise wireless deployments so if there are any tricks specific to low AP count environments I would be somewhat ignorant of them. The same could be said if there are more easily accessible wireless controls in Android than I am familiar with as, if there are, I still couldn't use them as different guests walk in each day and they all need to work.

Android tends to hang on to APs even if they're at a completely unusable signal level with no connection. Doesn't matter if fast roaming is enabled, doesn't matter if bss transition is enabled.

The only solution I've found is enabling the minimum RSSI feature on my APs, this forcefully disconnects any clients with a low signal.

Devices usually take 5-10 seconds to reconnect to the new AP after this happens, but will also sometimes will fail outright for a minute or more while Android insists on trying to connect to the old AP with a worse signal and keeps getting kicked off, before it finally gives up and connects to the stronger signal.

Raising the minimum data rate can also help, as long as none of your devices are really old and need them.

Yes. The proven method is to A/restrict data rates to just high ones and B/lower the transmit power of your AP so that your devices can no longer maintain high enough data rates after a given point and are forced to disconnect. I am almost certain the run of the mill stock firmware does not offer you this option. Look into installing OpenWrt.

Apart from that, OpenWrt now allows you to install and use usteer which offers a plethora of (802.11 standards-based) tools to manage client roaming from the AP side, including the APs exchanging information between themselves.

Search for Wifi roaming. To support Wifi roaming you need a wifi mesh though.

It’s up to you as the programmer! The library literally gives you the power to roam/connect to whatever you want whenever you want.

Yea, it's not super clear but that's indeed what I meant to say :)

> ESP32 doesn't automatically reconnect to the stronger AP

How would it know to reconnect to stronger AP?

You can order it to do a background scan and reconnect to stronger AP if you want, but you have to figure out how often to do this and how to interleave other data during the scan.

Other things using the 2.4GHz spectrum might have malfunctioned because of that and the users would have had no recourse. Even if you can, you should not do this unless there are no neighbors within range and you can ensure that you will never put anything else on 2.4GHz near it.

Also, I do not believe iOS ever added support for 40MHz channels on 2.4GHz. That feature never should have been added to WiFi. It causes headaches practically everywhere it is used.

[dead]