First time posting here. I have a real frusterating issue that I have been dealing with as an installer ever since our Company started having us select multiple channels on our SM's when we install them.
The issue is this: If I install a 5.7GHz 450, select 20, 30, & 40MHz channels and say for instance, the SM should connect to a direct line of sight to the North AP @ -59db, It will instead (sometimes) connect to the West, or East Ap @ -80db. And as long as it does not drop sesssion, it will stay connected to that AP, even at a very poor modulation.
This has happened over and over again with me, and all of our installers. I even tried selecting "AP Selection Method"="Power Level" and that sometimes helps, but not always. Sometimes I have to deselect the freqency that I dont NOT want the SM to connect to and leave it at that. The issue there is that if we ever have interference in that area, our Manager will choose a different freqency/channels on the AP, reboot and all customers re-connect at the new freqency, but If I have that particlualr SM's freqency unchecked, they will obviously drop.
I have tested many firmware's and all the latest firmwares have this issue. The one firmware that seems to work perfect is 13.2.1. This has happened not just with the 5.7GHz 450's, but the 2.4 and 3.65GHz 450's as well.
Has anyone had this issue, and if so, what was your workaround???
Without knowing what software you already tried it's hard to be sure, but there are at least 2 bugs with respect to similar scenarios to what you describe that have been fixed over the last year which you may be seeing.
If you are using 5ms frame, there was an issue fixed in 14.1.2 where the Primary AP was not seen in some cases, causing devices to connect to a secondary color-coded AP instead.
More recently, a similar problem was occuring, but not necessarily specific to 5ms frame (though 5ms frame would generally be more likely to see this problem), which has been fixed in 15.1.4 and 15.1.5.
15.1.4 is not a general release, and 15.1.5 is currently close to going to Beta, but if you contact customer support, you should be able to get a direct software load to try.
Alternatively, 15.1.5 open Beta and 15.2 open Beta will both contain these fixes, and should be out very soon.
I will PM you with info for a point of contact if you'd like to try the 15.1.5 closed Beta on your setup.
Hi Al, with my recent issue (since resolved) we were noticing that the CPE (on 15.1.1) would not re-scan after the idle period. Eg., on secondary or tertiary color code eg., 30 minutes, then wait 5 minutes at idle to rescan. I guess what I'd like to know is what kind of thresholds make the radio consider itself "idle"? Is this roughly the bug you mention being fixed in 15.1.4/5?
That said, when we removed the "wait for idle" requirement and forced the automatic refresh, it worked every time. I don't know when it was introduced, I've been using this system all the way back to version 10.something when secondary color codes were first introduced and it's worked well as far as I can recall.
Going back to the original posters question: what firmware are you running on ap's and sm's?
Do you have separate color codes for each AP, and use the primary (for the preferred ap) and secondary (for adjacent ap's) functionality? Other than my described bug above it's worked pretty good at doing exactly what you sound like you want to avoid happening.
Hi Al, with my recent issue (since resolved) we were noticing that the CPE (on 15.1.1) would not re-scan after the idle period. Eg., on secondary or tertiary color code eg., 30 minutes, then wait 5 minutes at idle to rescan. I guess what I'd like to know is what kind of thresholds make the radio consider itself "idle"? Is this roughly the bug you mention being fixed in 15.1.4/5?
That said, when we removed the "wait for idle" requirement and forced the automatic refresh, it worked every time. I don't know when it was introduced, I've been using this system all the way back to version 10.something when secondary color codes were first introduced and it's worked well as far as I can recall.
Actually the option "Subscriber Color Code Wait Period for Idle" setting was fixed in 15.2. That beta load should be out soon.
The problem with the waiting for idle, is that the SW was counting internal communication as welll, such as Power Adjust messages, which was making the SM never idle. But the SM does have to be completely idle, meaning zero traffic coming in it's ethernet getting bridged over the RF. So I'm not sure how likely this is to happen unless the customer powers down their WiFi router when they go to bed. I know I just leave my stuff all the time even when I'm not using it. :)
To add to what Charlie said, we’ve discussed possibly revisiting the idle SMs feature in the future, but unless we get a lot of requests for it, it’s a bit low priority due to not many customers asking about it, and the complexity of deciding what constitutes “idle” in the modern age of cell phones and computers “phoning home” over the network constantly.
Another option you can use is to not wait for idle and just require the SM to switch over based on timing alone, though we understand that could cause disruptions for your customers if it happens at an inopportune time. I would suggest calling support if the idle wait period feature is important to you, since we use customer feedback to decide what features need more development based on requests like that. Thanks!
Sorry for the late reply, been pretty busy latey (which is a good thing). Anyway, we are currently using firmware v15.1.3. We also seen these issues with 15.1 and up to current firmware, as far as older versions, I only tested v13.2.1 as I knew back in the day, it was a good, stable release and it did not produce the problems that I am having. Just dident have anough time during the work week to try other versions.
Like I said however, we only started seeing this issue when we started selecting multiple channels on the SM's, instead of just the one the AP is using. I personally use only the one the AP is using when scoping for a signal, because I dont like the long wait time having the SM search through all the freqencies, on all channels. When I leave a customers house, I select for ex: 20, 30 & 40MHz channels, make sure it connects to the right AP after Im done.
The frame time we are using on all of our AP's is 2.5ms as far as I know...I will check with our guy who manages all of our AP's to make sure, but I just checked 10 of our towers, and all the AP's were using 2.5ms frame times...
I got your PM, and would be interested in trying the beta firmware to see if that helps...
Sounds good, Keith! Judging from feedback we’ve received from other customers experiencing a similar issue to yours, I think you’ll be happy with the new software. Thanks!
Very sorry for such a late reply on my feedback from the Beta firmware you sent me. Just been crazy busy at work these past couple of months...
Anyway, I just wanted to let you know that so far, v15.1.4 Beta 6 has been performing very well! I have tried it 4 times now at customers house's when I have experienced the issue, and so far, it has fixed it problem. The SM will now connect to the AP with the strongest signal (based on its location) instead of a much weaker signal coming from another AP. No more unchecking freqencies, which we certainly dont want to do...
Thanks again, and look forward to the next firmware update!