wifi: scan 5GHz channels on dual-band radios - #11308
Conversation
983ad10 to
2bfc75e
Compare
|
As I understand it scanning is a passive activity, so there's no harm in scanning channels 12, 13, or even 14. I'm in the US, and I actually do see traffic on channels 12 and 13. It would be useful to see if there is something running that (presumably) shouldn't be. |
|
Looks like ESP-IDF handles active vs passive scanning for us. From here:
|
2bfc75e to
acb9559
Compare
|
Yes, that matches. Measured on the ESP32-C5, five trials each, all identical to 0.01 s:
|
|
2.4 GHz tested on this branch. No regression.
ESP32-C5-DevKitC-1-N8R8. |
Dual-band radios come up 2.4GHz only, and the scan API rejected any channel above 14, so 5GHz networks were unreachable. Gated on SOC_WIFI_SUPPORT_5G, so single-band builds are unchanged.
acb9559 to
117fa80
Compare
|
Can you mention why scan channels are 20MHz only? (e.g., no API to set protocol) |
|
Both protocol and bandwidth are not exposed ATM. That deserves its own separate PR. Last came up in #9790. |
|
Looks good. Please don't force push after a review has started because the old comments disappear with the old commit. Instead, push a new commit with the changes. |
Stacked on #11297. Base is
esp32c5-board, so only the top commit is new here.What
Lets
wifi.radio.start_scanning_networks()reach 5 GHz on dual-band radios.Why
Three things blocked it:
scan_patternstopped at channel 14SOC_WIFI_SUPPORT_5Gstop_channeldefaulted to 11DFS channels are left out. They need radar detection before transmitting.
Open question
Raising the default from 11 to 165 also changes 2.4 GHz boards, which now
scan channels 12, 13 and 14. 11 is the FCC-legal maximum, so that may have
been deliberate. Happy to make the default band-dependent instead.
Hardware tested
ESP32-C5-DevKitC-1-N8R8,
10.3.0-22-ge514194c68-dirty, host Ubuntu 24.04.That is the stack tip, so it also carries #11309, which does not touch scanning.
scan()scan(start_channel=1, stop_channel=165)scan(start_channel=1, stop_channel=11)scan(start_channel=36, stop_channel=165)scan(stop_channel=166)ValueError: stop_channel must be 1-165The 36-165 row is the skip fix: it starts above the 2.4 GHz part of the pattern,
and the scan completes instead of ending at the first rejected channel.
Not tested: a 2.4 GHz only board. The
scan_patternchange is gated onSOC_WIFI_SUPPORT_5G, but thestop_channeldefault of 165 applies everywhere.Scan channels
Channel numbers are 20 MHz primary channels. An AP on a wider channel beacons
on its primary, so it is still found, and the scan record carries its real
width in
bandwidth,secondandvht_ch_freq1.wifi_scan_config_thas no width field, and CircuitPython exposes no bandwidthor protocol control, so the driver default applies. Last came up in #9790.
AI assistance
Claude wrote the scan-skip loop and the docstring. I found both defects on
hardware, ran the scans, and verified the channel lists myself.