ESP32 in AP and STA mode is bad for your network

[JustMeHere]

I just discovered that having an ESP32 in AP and STA mode is bad for your network.  The AP mode will be on the same channel as STA.  This is the same effect as having two APs on the same channel.  I'm going to avoid this
I had my ESP32 set up this way for debugging/troubleshooting.   But it looks like it should be avoided in production.

[thm_w]

Is that an issue though? It just means the bandwidth will be shared.
https://www.upesy.com/blogs/tutorials/how-create-a-wifi-acces-point-with-esp32#

Of course if you are releasing a production product the debugging capabilities should generally be disabled.

[Shonky]

2 APs on the same channel is completely workable. Multiple APs can coexist together.

Obviously they have to share the channel bandwidth but that's about it.

[JustMeHere]

It kills range.  It's workable, but signal quality suffers.  I've set up wifi networks that host 100+ phones.  Separation of the channels is important.  I've seen two APs jam each other.  Unplugging the ESP32 device added 20 dB to my signal. quality.

[Shonky]

It kills range.  It's workable, but signal quality suffers.  I've set up wifi networks that host 100+ phones.  Separation of the channels is important.  I've seen two APs jam each other.  Unplugging the ESP32 device added 20 dB to my signal. quality.

It doesn't affect signal quality. Two devices can transmit on the same frequency and that's exactly what one AP and multiple STAs do all day every day.

APs shouldn't be "jamming each other" and if they are then they are very poor quality units. People run separate APs on the same channel in dense areas all the time.

You don't lose 20dB by plugging in a second AP.

If you insist on separating your AP and STA, you essentially need two radios and any basic WiFi device like an ESP32 will just not have that.

[dare]

If you insist on separating your AP and STA, you essentially need two radios and any basic WiFi device like an ESP32 will just not have that.

Yep, pretty common for a lot of WiFi chipsets I expect.  We (Nest) shipped a product that relied on simultaneous station / AP mode for set up.  Hardest part was getting iPhones to follow along during the inevitable channel hop when the device connected to the user's home AP.

[SiliconWizard]

I just discovered that having an ESP32 in AP and STA mode is bad for your network.  The AP mode will be on the same channel as STA.  This is the same effect as having two APs on the same channel.  I'm going to avoid this
I had my ESP32 set up this way for debugging/troubleshooting.   But it looks like it should be avoided in production.

Good to know, but indeed that would be a relatively odd configuration - I would even guess that most users of ESP32's are not aware of the possibility of using both modes at the same time.

[bookaboo]

It’s a fairly common mode used to set WiFi credentials. Though that use case is infrequent and brief. 

[Shonky]

It’s a fairly common mode used to set WiFi credentials. Though that use case is infrequent and brief.

You don't have to have AP and STA running simultaneously and I think most do not.

You put device in "setup mode". It then changes to an AP only. Your mobile device connects to that new AP to configure the SSID and PSK. The device then switches back to STA mode and connects to the user's AP. So no need to run them at the same time.

[bookaboo]

That's true but by having both you can run a webpage server on the ESP32 that informs the user of the status of connection to the WiFi router.

[dare]

... The device then switches back to STA mode and connects to the user's AP. So no need to run them at the same time.

Sure you can do it this way, but the user experience is pretty bad when they inevitably mistype the WiFi password.  Certainly not suitable for a consumer product, but possibly fine in a more technical (e.g. industrial) setting.

[artag]

That's true but by having both you can run a webpage server on the ESP32 that informs the user of the status of connection to the WiFi router.

You can do that even if the ESP32 is STA only. The webserver doesn't need to be on the AP. Of course, the status can't be 'disconnected'.

[thm_w]

... The device then switches back to STA mode and connects to the user's AP. So no need to run them at the same time.

Sure you can do it this way, but the user experience is pretty bad when they inevitably mistype the WiFi password.  Certainly not suitable for a consumer product, but possibly fine in a more technical (e.g. industrial) setting.

If the device can't connect to the AP (wrong password, not powered, etc.) it brings up the STA mode again. This is typical behavior for ESP8266/32 arduino.
Of course with a Nest it might be a pain in the ass to power the thing off and on again, so there might be some specific scenarios it could get stuck in and having both available is good.

[dare]

If the device can't connect to the AP (wrong password, not powered, etc.) it brings up the STA mode again. This is typical behavior for ESP8266/32 arduino.
Of course with a Nest it might be a pain in the ass to power the thing off and on again, so there might be some specific scenarios it could get stuck in and having both available is good.

The problem is the turn around time it takes the device to drop the AP, scan for the target network, connect to the network, attempt to auth, then bring up the AP again when something goes wrong.  Add on top of this need for the user to recognize that the device hasn't connected (presumably via some visual signal on the device), manually re-connect their phone to the device's AP, get back to the configuration screen and try again.  Even with support for simultaneous AP/STA mode, the various hiccups and delays that can happen during wifi setup often lead to user frustration and high product return rates.   We battled with this quite a bit in the early days at Nest.  That's one reason why so many devices use BLE during the setup process (although it's not without its own issues).

[SiliconWizard]

If the device can't connect to the AP (wrong password, not powered, etc.) it brings up the STA mode again. This is typical behavior for ESP8266/32 arduino.
Of course with a Nest it might be a pain in the ass to power the thing off and on again, so there might be some specific scenarios it could get stuck in and having both available is good.

The problem is the turn around time it takes the device to drop the AP, scan for the target network, connect to the network, attempt to auth, then bring up the AP again when something goes wrong.  Add on top of this need for the user to recognize that the device hasn't connected (presumably via some visual signal on the device), manually re-connect their phone to the device's AP, get back to the configuration screen and try again.  Even with support for simultaneous AP/STA mode, the various hiccups and delays that can happen during wifi setup often lead to user frustration and high product return rates.   We battled with this quite a bit in the early days at Nest.  That's one reason why so many devices use BLE during the setup process (although it's not without its own issues).

True.