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

[serviceberry]

You can run Arduino code on anything, since it's mostly just a bit of syntactic sugar around C. But I'm sure you know what I mean.

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.

[analog31]

There's always a few of us. ;-)

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.

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

[vachina]

I know what you mean haha.

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.

[RockRobotRock]

Who wants to deal with writing that logic for a hobby project? That doesn't sound fun at all.

Sounds like a "good enough" shitty solution to me, which is kind of the whole point of DIY.

[Vurdentium]

Deal with what? I would argue that if you're going to the effort of writing a blog post on the topic then you should at least go to the effort of skimming the docs to make sure there isn't already a solution for the common problem you're experiencing.

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?

[RockRobotRock]

Personally, I don't use multiple APs with overlapping SSIDs, but if I did than I can see how it would be easier to deal with the logic from the AP management side rather than the client. It's also nice to not have to re-connect IoT things if/when you add or change your APs.

[Vurdentium]

I'm not sure we're understanding each other so just to be clear, my suggestion is to change from this (pseudo) C:

  wifi_connection_config_t config = {
    .ssid = "my_home_wifi",
    .password = "secret123",
    /*
      implicitly initialised to default:
      .method = CONNECT_TO_THE_FIRST_AP_THAT_RESPONDS,
    */
  }

to

  wifi_connection_config_t config = {
    .ssid = "my_home_wifi",
    .password = "secret123",
    /* explicitly initialise: */
      .method = CONNECT_TO_THE_AP_WITH_THE_STRONGEST_RSSI,
  }

It's that simple.

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

[readmodifywrite]

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.

[bobmcnamara]

Often ESP32 devices at low power can still transmit, but will start to fail to receive acknowledgements.

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.

[bobmcnamara]

> The timing for this is deliberately set to be very conservative in terms of the wakeup window (at the cost of higher power)

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.