Bolt - APs on same channel

We have an in house ad-hoc test network setup where we have two different APs both on the same 2.4GHz Channel (11). Both these APs are placed on opposite sides of the building. It seems that the Bolt has a really hard time roaming between them. Sometimes taking the Bolt out of the range of the currently connected AP will still not reconnect to the other AP when it is in range unless the Bolt is power cycled. When doing a network scan on the Bolt itself it will only ever show the AP that it is connected to, and not the other AP that is on the same channel/SSID.

I realize that having APs on the same operating channels is not great network protocol, but we run into this sometimes in the field. Is there anything we could do on the Bolt that would help alleviate some impact of this issue?



Do you know what firmware you are on? Make sure you are on the latest firmware 2.03.02. Depending on what firmware you are on there were a few updates that improved roaming capabilities.

It might also help to take a look at the roaming WLAN ATS registers to adjust the roaming thresholds.

It is running the latest 2.03.02 version. The WLAN ATS registers are at their defaults. We were hoping that we wouldn’t have to make roaming adjustments to the radio like that. We are trying to migrate away from our current vendor because of issues with that specific issue. It is very impractical to adjust roaming settings for the hundreds of different customers/buildings/networks that we supply controls to.

Hi @ckracht,

Do you know what the rssi is when the device isn’t connecting? Could it be to low to allow it to connect? From the AT command window you can run AT*WSSCAN? This will print the available BSSID, SSID and RSSI. This should help you determin if the RSSI being to low is the issue.


The value is normally quite high, between -40 and -60, as we have it very close to the AP. In contract the AP it currently is connected to is quite low, between -80 and -100. During this time it also drops a lot of packets. When a WLAN scan is initiated from the Bolt Webpage it will only show the AP that it is connected to (maybe the Webpage drop down for WLANs is filtering based on SSID and Channel so it looks like the same AP?).

As soon as I set the APs to be on different channels (ie one on channel 6 and the other on 11), the device roams flawlessly.

The web page will only show the available SSID. This is where the AT command comes in handy. AT*WSSCAN? will show all BSSID’s which is typically the MAC ID if the AP. Does this also no show you both BSSID’s?

When I am back in the office next week I will mimic the original test and run this command and let you know the results. Thanks!

Thank you for the response.

We look forward to the results.

I am able to replicate the issue. Here is what I am seeing with the Scan command. The first example is what I see about every other scan or so, it only shows one LPCARTS24 network. Another scan a few seconds later may or may not show the second AP. In this example it is seeing the AP that it is NOT connected to (…-3F-8F) with a RSSI value of of -67.


After doing another scan after a few seconds, it now shows both. The AP that it IS connected to (…-6E-49) actually has a worse signal strength and should be roaming.


However it still will not roam to the AP with the better signal strength. Roaming RSSI diff threshold is set to 10, but there is a difference of 13 here. Trigger Scan RSSI is set to -70 so it should be looking for roaming candidates as it is at -80. When doing another Scan, it no longer shows the AP with the better signal strength. It might be that it keeps seeing and un-seeing the AP with the better signal strength, and this may be why it is not actually roaming.

AP it is connected to but shouldn’t be:

AP is should be roaming to:


When doing another Scan, it no longer shows the AP it is currently connected to. It may be that it keeps seeing and un-seeing one of the APs, or getting confused as to which is which, and this may be why it is not actually roaming.

Hello @ckracht,

It looks like you are working at the edge of the connection levels.

You could try lowing the roaming threshold to get to try getting it to move sooner. You can also try setting ATS4005=1 enabling roaming Neighborhood watch and improve the scanning.

Do the AP’s you are using support 802.11r? If try disabling this on the bolts, perhaps this is causing an unknown issue.


We send very small data packets over this connection, so I don’t need it to roam sooner. I just need it to roam when it’s expected to. As I previously stated, the Roaming Threshold is at -70 and since it’s attached to -80 strength it should already be trying to roam. When it searches, it sees a better AP with -67 (albeit not the greatest, but its better than the diff threshold which is set to 10, the difference is 13). Am I wrong in my calculations that it should be trying to roam to the other AP at this point? Even if that was the case, if I increase the power on the AP it should be roaming to, so the signal strength is much better, ie somewhere between -45 and -55, it still will not roam.

I really do think there is an issue here where it’s trying to roam between APs that are on the same Channel. If I adjust the channel in this example on one of the APs to be at Channel 6, the radios will then roam with absolutely no issues time and time again without adjust any settings on the radios. Once I switch them back to the same channels, the same issues presents itself where it will get stuck on one of the APs and never roam unless the radio is rebooted.

They do not support 802.11r. I have already disabled Fast Roaming, as that was causing issues with the radio locking up and requiring a reboot.

Once I have time to run this test again, I can try the Neighborhood Watch setting. This was not a setting available when we first received the Bolt, and it wasn’t in my AT Command Manual. I see a new one was published so have retrieved it. I am not sure when I will be able to test this though.

Could you create more of an overlap between the two AP’s? With such a low signal level having them close would give you more time to make a switch before the signal is lost entirely.


It had infinite time to switch, but it still didn’t. In the example I posted, I had the radio sitting statically on a desk, not moving. It never once lost it’s connection to the AP where the signal strength was around -80. It sat right around the same signal strength for the entirety of the test, and never jumped to the one that was around -65.

I am unable to physically move them. If I create more overlap between the APs (which I can only do using varying transmit powers on the APs) the radio will never roam because the signal strength will never drop low enough. I am forcing this scenario on purpose, because we have issues with it in the field which is a static environment that cannot be changed

Is there a reason no one will discuss anything related to the information I have presented about only having this issue when the APs are on the same Channels? I went through the leg work of providing a lot of information about what the radios are seeing during scans, and it seems it was ignored.


Having the two devices on the same channel is most likely the cause of the issues. I am waiting for my colleagues in Sweden to return from vacation to discuss this with them to see if they have any details on how the AWB should handle this issue.

While it should be roaming once it is below the thresh hold I suspect having the two ssid’s on the same channel is preventing it from migrating. Lowering the thresh hold to switch at a lower rssi strength might help.

Generally is not recommended to use the same channel with AP’s that overlap. This causes interference between the two. From the scan we can see there are several other BSSID’s using the same channel with stronger signals the the LPCARTS24 BSSID’s could be getting drowned out. This could be causing a exposed node problem.

I will be checking with my colleagues early next week for their input.


I understand that it is not good practice for them to be on the same channels. Unfortunately this is something we deal with a lot in the field. We do not have the ability to make any modifications to customer’s wireless networks. I look forward to hearing back sometime next week on any further suggestions. I appreciate the responses, thank you.

Hello @ckracht,

Discussing this with my colleague he points out that the while the decision to move to another AP is normally based on the RSSI, there are other aspects that come into play. In your setup there are several key parts working against the connection and the probe response requests might not be showing a clear channel so the client isn’t getting an opportunity to make the switch. Wi-Fi being half duplex, “listen before speak”, all stations have to be well behaved and take turns to transmit.

In your scan we can see 6 AP’s all competing for the same channel. There is also one device on channel 10 that overlaps with channel 11 and interferes without participating in co-channel cooperation.

If the issue is related to the roaming characteristics we recommends adjusting the roaming threshold to make it more prone to roam. The neighbothood watch ATS register 4005 should also help.


The Neighborhood Watch setting (ATS4005=1) does not seem to do anything. I recreated the test and it still will not properly jump. In this scenario I even made the signal very very strong on the AP that it should be jumping to, but it still will not roam from a very poor signal connection.

It is currently connected to AP2 (…6E-49) with a RSSI of -89 with no intention of roaming until it fully disconnects from this AP.

But if I do a scan from the Bolt you can see that AP1 (…3F-8F) has a MUCH better RSSI value of -63.


Do you have any other recommendations that can help? This might be a show stopper from using this in future implementations. In this very same test I can get a competitors wireless radio to roam back and forth even when the APs are on the same channel.

Hi @ckracht,

I am going to review this with my colleagues I would expect it to migrate. perhaps there is a minimum strength required for it to switch?

I’ll follow up shortly.


Has there been any follow up to this?