Earlier quoted context omitted.
Use osc instead
What's that?
OpenSoundControl
Easy protocol to control devices
ESP32 WiFi Superstitions
81–86 of 86 posts
Re: ESP32 WiFi Superstitions
#82Mine is to manually poll every once and a while and restart the WiFi if it's not connected. I generally find ESP32 WiFi to be very reliable.
I wonder if there's some special high security setting or OpenWRT router or something that they don't like?
Whenever tech people say something is unreliable, I sometimes wonder if they're using it in a non-stock way, and if that is part of what causes the issues.
Re: ESP32 WiFi Superstitions
#83Earlier quoted context omitted.
> 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 car…
> 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.
Re: ESP32 WiFi Superstitions
#84Earlier quoted context omitted.
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 car…
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.
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.
Re: ESP32 WiFi Superstitions
#85Earlier quoted context omitted.
I can think of only a single time where 40 megahertz on 2.4 gigahertz was the right choice for a product (designed for outdoor use, battery powered). File download time decreased by about 40% on Android but not at all on iOS - turned out at the time they only supported 40MHz+ on 5.8GHz.
Other things using the 2.4GHz spectrum might have malfunctioned because of that and the users would have had no recourse. Even if you can, you should not do this unless there are no neighbors within range and you can ensure that you will never put anything else on 2.4GHz near it. Also, I do not believe iOS ever added support for 40MHz channels on 2.4GHz. That feature never should have been added to WiFi. It causes he…
Could probably do a scan to tell if 40MHz or 20MHz was better, but practically these devices are not used in areas with neighbors. The cool part was that our noise floor was great.
> It causes headaches practically everywhere it is used.
It really does - we got a few complaints that the latest iPhones took twice as long to sync as crappy Android phones. Not enough that I would choose differently on the next one, but something to consider.
The other wonky thing was that the usual channels 1/6/11 become 1+6 or 6+11, always up against guardband limits, but reducing power impacts bitrate across the entire bandwidth. Channel 4+9 didn't have this issue but overlaps with all 20MHz channels. I hear the newer WiFi specifications are better at managing this.
Re: ESP32 WiFi Superstitions
#86Earlier quoted context omitted.
I use Fresh Tomato as the firmware on my router, but I don't see anything in the documentation about "usteer". I'll search for a different term. I'm sure they have something, because they have a lot of active development.
> dedicated for routers with Broadcom chipset You see, the first thing I look for when I want to buy a new AP is for it to NOT have a Broadcom chipset ( https://openwrt.org/meta/infobox/broadcom_wifi )
Can you recommend a decent AP without Broadcom? I've used FreshTomato exclusively for many years and haven't shopped for other alternatives.