Re: [CODE SNIPPET] How I connect to an AP

This is the sort of discussion I hoped would happen 
My particular device is deployed in quantity (100's to 1000's) in cities where the Wifi is very polluted. I've found that avoiding any sort of scan of APs is a very good idea. Using this code has reduced my start up and connect time from sometimes over 10 seconds, to under half a second in most cases. My devices are solar and dry cell battery powered, and spend as much time in deep sleep as possible, waking mostly to send a heartbeat and to check for commands and to send event data.
City provided Wifi uses the same SSID on hundreds of stations, each with a different BSSID. They also typically set their hardware to automatically change channels to find the least polluted. My devices are static (strapped to light poles or mounted on walls), and they typically see 3-4 stations with the same SSID, different BSSIDs and different strengths. The code that populates the list of APs is dynamic and uses the rssi, and number of failed connect attempts to adjust the list, and the connect code uses the BSSID to always attempt connection to the last 'best' specific station first.
BTW a fast reconnect is done by using both BSSID and channel. A Wifi channel is the most unreliable element of the connection for a station as routers can be set to channel hop in order to find the clearest signal, but channel is also the most expensive thing to leave out because if you don't specify a channel the radio has to scan through them to find the SSID. Also most scans are not smart - the most commonly used channels tend to be 1, 6 and 11 but most scans will go in numerical order. And when you have 4 stations all with the exact same SSID but different connection quality or strength, you want to pick the best one.
This is why I don't use the built in SDK capability and why I store info on the last connection in RTC memory.

My particular device is deployed in quantity (100's to 1000's) in cities where the Wifi is very polluted. I've found that avoiding any sort of scan of APs is a very good idea. Using this code has reduced my start up and connect time from sometimes over 10 seconds, to under half a second in most cases. My devices are solar and dry cell battery powered, and spend as much time in deep sleep as possible, waking mostly to send a heartbeat and to check for commands and to send event data.
City provided Wifi uses the same SSID on hundreds of stations, each with a different BSSID. They also typically set their hardware to automatically change channels to find the least polluted. My devices are static (strapped to light poles or mounted on walls), and they typically see 3-4 stations with the same SSID, different BSSIDs and different strengths. The code that populates the list of APs is dynamic and uses the rssi, and number of failed connect attempts to adjust the list, and the connect code uses the BSSID to always attempt connection to the last 'best' specific station first.
BTW a fast reconnect is done by using both BSSID and channel. A Wifi channel is the most unreliable element of the connection for a station as routers can be set to channel hop in order to find the clearest signal, but channel is also the most expensive thing to leave out because if you don't specify a channel the radio has to scan through them to find the SSID. Also most scans are not smart - the most commonly used channels tend to be 1, 6 and 11 but most scans will go in numerical order. And when you have 4 stations all with the exact same SSID but different connection quality or strength, you want to pick the best one.
This is why I don't use the built in SDK capability and why I store info on the last connection in RTC memory.