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.
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).
My point is that people who are attracted to Arduino are, by and large, not the kind of people who want to geek out about the inner workings of the MCU, and there's nothing wrong with that.
I'm pretty familiar with the microprocessor architecture of the 8-bit era that I grew up in, and have done a fair amount of hardware hacking. As things have gotten more complex, I've let some things slide, such as the complexity of pipelined architectures.
Arduino is not even syntactic sugar any more. All it retains of its origins, that I'm aware of, is the weird setup() and loop() schtick. And you have limited control over what happens before your code starts. But with most Arduino compatible boards, you have full access to the vendor supplied libraries, and can go as deep as you want. These days my preferred platform at work is Teensy 4, and at home, the wireless enabled boards. I think Paul Stoffgren is some kind of 100x engineer.
But life is short. Over my 61 years, I've carefully rationed the brain cells that I devote to innards of technologies that will soon be obsolete. I read the Turbo Pascal manuals cover to cover, and The Art Of Electronics, but I never cracked Inside Macintosh. I've decided that I will simply not learn anything about any OS that is not Linux, and superficially at that.
I program desktop computers in high level languages, despite total abstraction of the innards.
I think the relative portability of Arduino code has been a huge boon for hobbyists because it encourages the formation of a community of people who can share code and knowledge, even if they're not all using the same processors, and despite sometimes needing to tweak code when porting it from one platform to another. This was also the case with early FORTRAN. Portability across processors revolutionized scientific computing.
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.
Sounds like a "good enough" shitty solution to me, which is kind of the whole point of DIY.
It's literally one word to change in his WiFi config to get the behaviour he wants. It's already implemented. Who can't "deal" with that?
wifi_connection_config_t config = {
.ssid = "my_home_wifi",
.password = "secret123",
/*
implicitly initialised to default:
.method = CONNECT_TO_THE_FIRST_AP_THAT_RESPONDS,
*/
}
wifi_connection_config_t config = {
.ssid = "my_home_wifi",
.password = "secret123",
/* explicitly initialise: */
.method = CONNECT_TO_THE_AP_WITH_THE_STRONGEST_RSSI,
}
Instead of spending x2 the initial effort to fix the root cause, you spend x1 the initial effort to implement jank and then spend x10 the effort down the line maintaining the jank.
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.
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.
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.
If your supply can't handle the modem sleep mode it definitely isn't going to transmit reliably either.
I have a guess, but no real way to test what's happening. On the scope the start of a transmission says the supply hard, but most of the packet the ramp rate is relatively low. Once the transmission stops and the radio turns over to receive mode, the ramp rate is much faster. On a third device I can record packets and see that they are being sent and acknowledged, but often retransmitted by the ESP who didn't seem to hear the acknowledgement.
Yes, the minimum interval of when to start listening is determined by both radios clock accuracy budget, one of which can be known and the other assumed.
> so the radio is probably powered up for a good 5ms before the beacon arrives.
No, not anywhere near that long. I don't have a board wired out for current measurements, but for reference, 5ms/101ms beacon with DTIM=1 would be a 5% duty cycle without any useful data, unacceptably high for many battery powered devices.
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.
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.