Note how this might be "Wifi 6", but it's still 2.4Ghz only and as far as I can see still single antenna (making most mimo functionality useless). Target Wake Time looks like the only feature that might be useful (reduces battery consumption substantially), but few applications can make use of that yet because your product still needs to work if the user has an old router which doesn't support it.
Other ESP32's in the range don't get more than about 20Mbps throughput under ideal conditions, so it probably isn't exactly a beast in the wifi performance department.
In fact, I wouldn't be surprised if this isn't the same silicon with an upgraded firmware to enable this new functionality.
Shouldn't the fact that it's WiFi 6 mean it uses much less air time? I thought WiFi 6 was designed for this scenario with many clients. 2.4GHz is a bonus for low bandwidth iot devices where range trumps throughout.
Yes, 802.11ax added all the technology required to allow subchannel slicing in both the time and frequency domains.
Lets say you had a 5ghz 8x8 160mhz AP (maximum allowable by spec): if all you had were 1x1 20mhz clients, you could theoretically have 64 different clients concurrently communicating with the AP without any real problems.
2.4ghz does not have 160mhz channels, but allows up to 40mhz. Ignoring the fact that 2.4ghz is incredibly congested, and you will never achieve peak performance, you can still achieve a theoretical maximum (again, with 1x1 20mhz clients) of 16 concurrent clients.
That said, I'm more interested in 802.11be: MIMO across bands. Instead of hard disabling 2.4ghz (which I 100% recommend all people do: this cures all Wifi ills; and if you have a building that eats 5ghz, either move or spam APs), the AP will dynamically use 2.4ghz as a possible MIMO band.
Theoretical maximum configuration of 802.11be is 40+160+320 (one 40mhz 2.4ghz channel, one 160mhz 5ghz channel, 1 320mhz 6ghz channel), and 802.11be devices will simultaneously communicate across all of them; maximum MIMO configuration has also been increased to 16.
In other words, the future is an AP that looks like a hedgehog, and has 10gbit port.
> if you have a building that eats 5ghz, either move or spam APs
The insanity of moving just to get better wifi reception aside, do you mean move to North America where houses are built out of cardboard and sticks? Most other countries build walls out of solid materials and 5 GHz isn't getting through more than maybe one of those.
As for spamming APs, I really wish it were that simple. Apple devices cling to their AP until speeds drop to the dialup days and other platforms aren't much better. How did we figure out GSM roaming in the 90s but WiFi roaming is still a disaster 30 years later?
If you've set up many APs already, and find client devices sticking to them too strongly, this is a sign to turn down transmit power on the AP in question. Most ship set to "Max" which is terrible for SNR and spatial separation. Turning down transmit power will cause the client to switch sooner, non-intuitively providing more bandwidth due to better utilization of spatial separation.
I've seen that work well in open areas where APs overlap significantly, but in places with walls where you walk from one bubble to another, it still usually takes to long for a device to figure out it should switch and then actually do it. I've never had a video call even stutter when moving between LTE cells, but on WiFi, calls sometimes drop outright, even when walking down a long hallway with many APs.
The mere fact there is a single knob for 'transmit power', rather than the transmit power being automatically determined by the clients location relative to the AP, other AP's, and noise sources tells you a lot about the maturity of WiFi as a spec...
Deploying Ubiquiti's APs in managed (as opposed to standalone) mode makes this easy; even iPhones will transparently be passed from one AP to the next. I agree, though, the OSX/iOS roaming preference tuning is a bit batshit; they also refuse to drop your house's Wifi as you're driving away and want to switch to LTE ASAP.
Commodity/consumer APs aren't designed for handoff.
OH!!! Now I understand why people say 5Ghz doesn't go though walls!
I knew other countries had heavily walls but didn't make that connection.
I quite like our cardboard walls though, they are trivial to repair and upgrade, and they rarely get damaged in real life, except if a Real Tough Guy punches one.
As long as there isn't any other stuff on 2.4 GHz, it can indeed be beneficial.
But if there are any legacy 802.11 (especially pre-802.11n) or non-802.11 transmitters nearby, it can be catastrophic for throughput, both because you need protective measures when transmitting (so that older 802.11 versions can reliably detect your transmissions as occupying the carrier) and because some of them just don't cooperate well with 802.11 at all (e.g. Bluetooth, which will just happily transmit over 802.11 without any regard for CSMA/CA fairness at all).
The lack of 5Ghz in all their products is... surprising...
There are plenty of home users with 5Ghz only networks, which in turn means anyone designing an IoT device will get user complaints and returns from all these users.
>There are plenty of home users with 5Ghz only networks
really? is this a configuration that some ISPs are shipping in their routers, or how is this happening? i've never heard of anybody with a 5GHz only home network.
It's certainly somewhat common for more tech savvy folks to go out of their way to ensure their devices use 5Ghz when compatible.
But ISPs? Router manufaturers? No way in hell, why would they self-impose additional support burden by preventing the customer from connecting their 4-5yo old low-end laptop or their shiny new smart bulbs or their brand new Amazon Kindle?
That's an odd configuration, because having a 2.4 GHz network that all the shitty IoT devices can be on is one of the best remaining uses of that band.
2.4 is still the best choice for range and penetration (through walls etc.) if you don't need the speed of 5ghz. I'm honestly surprised if they're shipping 5ghz-only consumer access points.
> The lack of 5Ghz in all their products is... surprising...
Is it? Are there any competitors in the class have 5ghz support? Most of the radio MCUs I've seen are all 2.4ghz which includes thread/zigbee/wifi/etc.
To be fair, Espressif aren't the only ones. SiLabs announced the SiWx917 eons ago, and they finally appeared on Digi-Key like 3 weeks ago, but only in bulk, and the only dev board available is $200, and no Zephyr support, and this, and that...
> single antenna (making most mimo functionality useless)
Can't the AP still use MU-MIMO even for single-antenna clients? That's still a significant improvement every time more than one STA is active, especially in the super-busy 2.4 GHz band.
This is the type of device where 802.11ah (recently popular on the front page again) or LoRa is killer. Unless you need your ESP32 to push 10s of Mbps all the time you can instead use something which punches through multiple walls with ease, doesn't compete with high speed devices, and has power saving things like TWT years ahead of high speed Wi-Fi standards.
Yes, but (nearly) every potential buyer of IoT device has 2.4Ghz WiFi network at the location that said IoT will be deployed.
LoRa will require some kind of bridge device, and since we can't agree on anything - each vendor will have their own bridge device.
Alternatives like Amazon Sidewalk and Helium could work, but:
- Helium means users will pay for traffic to someone and use someone's internet connection. Doubt it will fly. It would be cool in a post-apocalyptic world, though.
- Amazon Sidewalk isn't universal and, IMO, immoral (enabled on devices by default without informing the owner of the device). Good luck downloading updates to your light bulbs at 80Kbps.
Other ESP32's in the range don't get more than about 20Mbps throughput under ideal conditions, so it probably isn't exactly a beast in the wifi performance department.
In fact, I wouldn't be surprised if this isn't the same silicon with an upgraded firmware to enable this new functionality.