Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESP32 WiFi Superstitions

supakeen.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: ESP32 WiFi Superstitions

#61

Post by [deleted] »

deskr wrote: post #57
phoronixrly wrote: post #8

Props to OP for using the term 'superstitions'. Wi-fi (and radio in general) is poorly understood even by people with engineering degrees, let alone the average Joe. This often leads to trying random stuff until an improvement is perceived (or believed to be...), then spreading this experience as proven and applicable in any context with no further research and confirmation of the results (let alone filing bug report…

> then spreading this experience as proven and applicable in any context It's worse. People don't even need to have personal experience to spread misinformation. They just read it online and then spread it like gospel. Misinformation in the likes of "Wood glue it stronger than wood", "Burning Diesel/Kerosine can't reach temperatures required to melt steel".

[deleted]

Re: ESP32 WiFi Superstitions

#62

Post by zamadatix »

Liftyee wrote: post #41
zamadatix wrote: post #4

> If your network hardware allows it, you should pin the device to the closest one. In Wi-Fi it's always the client's choice on where to connect to at the end of the day and any hacks the APs try to do to steer clients are "suggestions" at best and "signal ruiners for everyone" at worst. You may be better off specifying which specific AP you want to connect to by specifying the BSSID argument in the WiFi.begin() call…

If it's mainly (largely) static IoT devices connecting to an SSID, why not make the SSID hidden so it doesn't fill device screens (controlled by humans who probably don't want the IoT network)? Most commercial IoT products I've used have an option to type a hidden SSID, and your own C++ code definitely can do that.

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 " 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.

Re: ESP32 WiFi Superstitions

#63

Post by venusenvy47 »

phoronixrly wrote: post #13
venusenvy47 wrote: post #11

Earlier quoted context omitted.

Do you know of something that could get my Android tablet to switch between two AP's in my house? When I change locations in the house, it will never change to the stronger one if it has even the weakest signal that it was connected to. I can't find any Android app that tells the device to "change to a new AP if it is stronger than the current one".

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 off…

I use Fresh Tomato as the firmware on my router, but I don't see anything in the documentation about "usteer". I'll search for a different term. I'm sure they have something, because they have a lot of active development.

Re: ESP32 WiFi Superstitions

#64

Post by Saris »

venusenvy47 wrote: post #11
zamadatix wrote: post #4

> If your network hardware allows it, you should pin the device to the closest one. In Wi-Fi it's always the client's choice on where to connect to at the end of the day and any hacks the APs try to do to steer clients are "suggestions" at best and "signal ruiners for everyone" at worst. You may be better off specifying which specific AP you want to connect to by specifying the BSSID argument in the WiFi.begin() call…

Do you know of something that could get my Android tablet to switch between two AP's in my house? When I change locations in the house, it will never change to the stronger one if it has even the weakest signal that it was connected to. I can't find any Android app that tells the device to "change to a new AP if it is stronger than the current one".

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.

Re: ESP32 WiFi Superstitions

#65

Post by Saris »

fadedsignal wrote: post #42
venusenvy47 wrote: post #11

Earlier quoted context omitted.

Do you know of something that could get my Android tablet to switch between two AP's in my house? When I change locations in the house, it will never change to the stronger one if it has even the weakest signal that it was connected to. I can't find any Android app that tells the device to "change to a new AP if it is stronger than the current one".

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

Mesh is not required at all to use 802.11r

Re: ESP32 WiFi Superstitions

#66

Post by shadowpho »

doormatt wrote: post #34
shadowpho wrote: post #21

>It seems that when an ESP32 connects it goes straight for the first access point it sees. No! You as programmer control that. You can configure to connect to any AP you want. My code does a scan and save the closest AP. If it can’t connect it does another scan and saves a new AP

I think they're claiming that it won't roam between APs with identical SSIDs.

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.

Re: ESP32 WiFi Superstitions

#68

Post by shadowpho »

supakeen wrote: post #48
doormatt wrote: post #34

Earlier quoted context omitted.

I think they're claiming that it won't roam between APs with identical SSIDs.

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

Then change your code.

Every AP has a bssid (MAC address) that you can use to connect to specific AP.

It’s up to the code to figure out which one to connect to. The libraries have all the options.

When you do a scan you get bssid of the AP and strength of each signal. You can make a determination of when to rescan and reconnect.

Re: ESP32 WiFi Superstitions

#69

Post by readmodifywrite »

Vurdentium wrote: post #33
bobmcnamara wrote: post #25

Earlier quoted context omitted.

> 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 fac…

A) The timing for this is deliberately set to be very conservative in terms of the wakeup window (at the cost of higher power), so the radio is probably powered up for a good 5ms before the beacon arrives. I don't know if you could unintentionally design a 3V3 supply so poor that it takes in the order of milliseconds to adjust to an output current of about 30mA -> 80mA. B) Yes, this is a fair point, and why I was car…

Not to mention the TX power ramps up in microseconds to quite a lot more than 80 mA.

If your supply can't handle the modem sleep mode it definitely isn't going to transmit reliably either.

Re: ESP32 WiFi Superstitions

#70

Post by shadowpho »

ranma42 wrote: post #55
shadowpho wrote: post #21

>It seems that when an ESP32 connects it goes straight for the first access point it sees. No! You as programmer control that. You can configure to connect to any AP you want. My code does a scan and save the closest AP. If it can’t connect it does another scan and saves a new AP

I do actually see the problem that the ESP32 doesn't automatically reconnect to the stronger AP. I think this gets triggered when then stronger AP is briefly unavailable (reboot or radar scan or whatever) and it switches to the weaker AP, but then once the stronger AP is back it stays connected to the weak AP. (This is with multiple APs in a mesh configuration)

> 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.

Post reply on HN