[Vurdentium]

Yes this is a skill issue.

But Arduino ecosystem is full of superstition and bizarre hacks. It's cargo cult electronics. They will do anything to avoid reading documentation or writing robust code.

Even the power saving recommendation here reeks of it. There is no effort to understand it. Someone on an Arduino forum recommends it, others start to echo it to try to appear like they know what they're talking about, it becomes lore in the Arduino world and you out yourself as a clueless newbie if you don't know to do esp_wifi_set_ps(WIFI_PS_NONE) without questioning anything because that's just the way it's done. 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.

[serviceberry]

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.

[toast0]

> If they did, they would be using a "bare" microcontroller better suited for their needs and costing one tenth the price.

Where do you get something like an ESP that's one tenth the price? ESPs are cheap and you can run Arduino, ESP-IDF directly, or fringe environments (I had some ESP8266 running NodeMCU because Lua made more sense to me than Arduino).

[Vurdentium]

The problem isn't with the artist doing a one-off project involving a microcontroller. It's the Arduino "experts" who write blogs, create videos, and dominate forums with their accumulated nonsense. They posit themselves as authorities in the space, newbies adopt and echo whatever rubbish they make up, and the cycle continues. They get very defensive if you try to correct them, even linking directly to documentation supporting it.

If you're going to write a blog about how the ESP32 doesn't connect to the strongest AP so you need to pin it to a specific BSSID in your router settings... Maybe you shouldn't be writing that blog. If you haven't taken at least a moment to check documentation and see that the behaviour you want is already an option that can be selected by changing literally one line in your ESP32's WiFi config. Instead this pseudoscience proliferates.

[toast0]

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

[mort96]

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.

[bobmcnamara]

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

[Vurdentium]

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 careful to specify a "quiet" station above. If actively transmitting then there is likely a benefit to disabling power saving, but unlike Arduino bros I will admit at this point that I don't understand the WiFi spec well enough to comment further with any confidence.