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

31–40 of 86 posts

Re: ESP32 WiFi Superstitions

#31

Post by analog31 »

serviceberry wrote: post #24
toast0 wrote: post #16

Earlier quoted context omitted.

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

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 .

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.

Re: ESP32 WiFi Superstitions

#32

Post by pjdesno »

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…

I love the term "superstition". I like to refer to lab "rituals" - if something works, repeat it, and never change things around "because it ought to work just as well". Life is too short to figure out all the unknown variables that might be affecting things, so seize luck when you find it.

Re: ESP32 WiFi Superstitions

#33

Post by Vurdentium »

bobmcnamara wrote: post #25
Vurdentium wrote: post #6

Earlier quoted context omitted.

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…

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

Re: ESP32 WiFi Superstitions

#34

Post by doormatt »

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.

Re: ESP32 WiFi Superstitions

#35

Post by Vurdentium »

RockRobotRock wrote: post #29
Vurdentium wrote: post #18

Earlier quoted context omitted.

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…

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.

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?

Re: ESP32 WiFi Superstitions

#36

Post by RockRobotRock »

Vurdentium wrote: post #35
RockRobotRock wrote: post #29

Earlier quoted context omitted.

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.

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?

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.

Re: ESP32 WiFi Superstitions

#37

Post by yjftsjthsd-h »

I wonder if the attempts to replace parts of the network stack with FOSS ( https://news.ycombinator.com/item?id=38550026 ) would help with this? At the very least it would let you get more visibility into what's going on when things don't work, and in the best case it'd let you replace the firmware that's creating problems with firmware that doesn't have those problems. (I think.) Of course this depends on the bits you replace being the parts in play.

Re: ESP32 WiFi Superstitions

#38

Post by fc417fc802 »

pjdesno wrote: post #32
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…

I love the term "superstition". I like to refer to lab "rituals" - if something works, repeat it, and never change things around "because it ought to work just as well". Life is too short to figure out all the unknown variables that might be affecting things, so seize luck when you find it.

Having a protocol for working with a black box is fine. The problem is how bad a lot of people are at differentiating between superstition, a black box, and a process with a well understood mechanism.

Re: ESP32 WiFi Superstitions

#40

Post by Vurdentium »

RockRobotRock wrote: post #36
Vurdentium wrote: post #35

Earlier quoted context omitted.

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?

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.

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.
Post reply on HN