I have a problem with the P1 modules I use - they do not connect to the accesspoint with the lowest RSSI (column 5). In my infrstructure I have the following three accesspoints:
The device obviously should have automatically selected the first of these, but it insists on using the second one that unfortunately shares the wifi channel (10) with a neighbouring company. Due to this, the signal is MUCH lower than the -69 RSSI suggested in column 5 for the second entry. The OSX Wireless Diagnostics indicates -101 noise level (column 6) for this specific BSSID. It is not possible to select this from either CLI or Android as far as I know. Extending a wifi setup like this is becoming more and more common - also for consumers so we need a way to solve this.
I’m curious how the auto selection of AP’s works? I’ve read up on all the threads mentioning BSSID and I cannot find any details on how this is implemented and how I could use the API to instruct the device to NOT use the AP with the a4:2b:b0:a5:b4:xx address. I’ve looked through the firmware files and cannot find anything other than reading BSSID’s so I presume this is part of the WICED api that we cannot see.
Maybe for instance @mdma could shed some light on how we can make this work?
In contradiction to posts by any number of Elites or Particle, my experience is that a Photon will by default ALWAYS connect to the last configured AP NOT the AP with the strongest signal, as far as I’m concerned its a bug.
Pretty certain you will find lots of “strongest signal” statements on this forum.
I have a unit next to me, it is ~4ft from an ASUS RT-N56U router on an uncongested channel and a reported signal stength of ~50dB, in the next room on a channel that overlaps with multiple networks from a neighboring office is our Draytek router to which the Photon reports an ~80dB signal.
If I reset the photon it will connect to the Draytek unit, then at some random point it will decide that’s no good and switch to the ASUS one instead.
I think the OPs issue here highlight two problems with the current behavior.
1)An AP (potentially outside of your control) can affect your connectivity, this can also affect function if it keeps making connection attempts.
2)Failing to choose the strongest signal has the same effect as 1), if your device moves around the building this could be very annoying.
Pretty sure I will, but I'm somewhat reluctant to believe that any of the Elite or Particle staff had explicitly stated that the stronges WiFi would be picked, but that was what you implied with your statement.
BTW, there are some Elite statements from befor your finding
Or if you think of statements like this
mark the insertion "(I think)" which expressed self-doubt
or
where "i belive the core" and limit the statemens truth-claim and application to other devices than the Core too.
The 802.11b spec says devices should choose the strongest signal but it is up to the devices to do that. The spec doesn’t say how long that should take or what the algorithm or switching points should be, so that is up to the designers to figure out. One of the problems with 802.11b is that a slow device can cause the entire AP to run at a slower baud rate and so signal strength doesn’t really always tell the entire story of which AP would be “best”. Your -48dB close router might be running a 1Mb/s channel for a slow device while your -80dB AP might be running at the full 11Mb/s. I do not think Photon does this but it is possible. The 5GHz 802.11 specs have largely fixed this problem.
I have more than 20 AP’s in “view” at my house and I have had to carefully select channels for my three APs (with three SSIDs) to coordinate. Even then my phone sometimes makes a less good choice and I have to manually switch it to another SSID, so I don’t think this problem is limited to Photons.
In Photon, I believe that all SSID/BSSID selection happens inside the WICED stack which Particle cannot show you but if agree to a non-disclosure at the Cypress site you can look at the WICED stack there too. I can certainly believe that it tries the APs in some order (maybe last one first or other choices as @Moors7 suggested) and decides to switch using some algorithm. You can research this if you want.
Finally I don’t know of a way to make a device associate with a particular BSSID other than by blocking certain MAC addresses in the access point you don’t want to associate with (not in the device). I think if the device has the credentials, it can and will negotiate for an AP using its own algorithm about what it thinks is best.
@bko that’s both good and bad news I guess? I think I have the NDA with Cypress, so I’ll see if I can find it. Then again - I couldn’t really disclose my findings here for others to use, could I? :-/
I the “last known good” config is very likely how it is today. That means that if you have a network setup like this and want to test what happens when the network falls down … the device will just jump over to permanently using a less suited and more noisy network. Not very convenient.
Clearing stored WiFi and EEPROM settings does not reset this. It always connects to the same AP, so that means that the WICED stores the BSSID’s internally and use these for connecting. This is not exposed in the Particle API, so there is no way we could solve this problem unless some new features are added. Up until something like that is added, we basically have to walk around the office at midnight turning on/off routers until in connects to the correct one…?
@mdma that good news, but I still can’t see a way to connect to a specific BSSID? If I have three AP’s called “HomeNetwork” - how could I connect to the second one of these? I know the BSSID since that is returned in the scan…
My solution became to display the bssid on the device’s debug screen to help resolve this. For now I think that’s the only way to solve this. You get the bssid in scans that you perform yourself.
You can of course build some smartness into your software that scans and then selects the AP with the lowest RSSI value.
Just to be sure I understand - you didn’t find a programmatic way to set the AP to connect to based on BSSID? We do have photon code developed that can scan and list APs and can see the BSSIDs but need a way to connect to an AP by BSSID.
In our current product we run into a significant number of networks (that we can’t control) where a manual scan and simple algorithm for trying all APs until we get a working one (using ping checks) is the only reliable way to keep units online. Signal strength (or any other information we get at scan time) ends up being pretty unreliable for our use cases.
I know you said you were going to try to review the WICED code and you seem to have looked into this the most. Is there hope for us?
@jenschr Any insight on the last @badslug questions above? If there is a way to actually set and connect to a specific BSSID, that would be a great help. We had the same issue on a different module and were able to programmatically resolve which increased our reliability and stability greatly. Thanks in advance for any additional information you are able to provide.
I’m sorry, but there’s no way to do this that I know of that does not require that you rewrite this file https://github.com/particle-iot/firmware/blob/develop/hal/src/photon/wlan_hal.cpp (and thus makes you maintain the System files yourself). If you just search that file for the string “BSSID” you’ll see where that is used. BSSID is unfortunately only available for info - not for making a connection.
I’m guessing that there might exist ways to connect to a specific BSSID in the WICED SDK, but that you may have to sign an NDA to get access to the details?
