Back when 15.1 firmware was pretty new, there were several threads about how the DFS detection algorithm seemed to have been changed, and the effective result was a lot more false DFS detections. At the time, it seemed that 15.0.2 f/w was the last of the versions which had the older, more stable algorithm, so a lot of operators had reverted the APs which were plagued by these false detections to that version of f/w.
Since then, I do not recall seeing any mentions of the issue in new version release notes, or any further chatter on the forum about it. Are the newer, 16.0.x versions still using the same twitchy algorithm from 15.2, or are they more stable?
I haven't seen anyone bring up any DFS issues as of late. We're running 16.0.0.1 across our entire network and we have a few PMP450i AP's running on DFS channels and haven't had any issues... that being said, we've never really had a lot of DFS issues to begin with.
It's very much still an issue. Like you, our only resolution was to downgrade to 15.0.2. Thankfully we don't have any 450M AP's in DFS yet and downgrading to 15.0.2 will not be an option.Â
Hey guys. To the best of my knowledge, we haven’t changed anything major with DFS in some time, other than fixing some rare cases of falsing in ETSI regions over the last 2 years, one of which was caused by extreme proximity to an interference source of radar.
That said, our DFS detection system has not taken any substantial changes, but we do often have to tweak power values and such as regulations change between releases.
If you are having specific issues of falsing, I would encourage you to contact support so that one of our engineers can monitor the system and see what might be causing it. As I mentioned earlier, we had one customer with a radio just miles from a Radar installation that wasn’t directly on the same frequency but was “loud” enough to cause problems with our detection. The only way to resolve it was to work closely with them.
If we were dealing with a site getting 3 false detections in a month, rather than one or zero, I'd happily push that AP up to 16.0.1 and contact Cambium about it. However, when the problem manifests, sometimes, the primary and both of the alternate frequencies can be affected, and the end result is an AP which simply can't find a clean chunk of spectrum in which to transmit, so we have a lot of annoyed customers who are down for a fairly long duration while we scramble to fix it. Dropping to 15.0.2 usually stops the problem, so that is probably the path we'll continue on until we hear otherwise.
If we were dealing with a site getting 3 false detections in a month, rather than one or zero, I'd happily push that AP up to 16.0.1 and contact Cambium about it. However, when the problem manifests, sometimes, the primary and both of the alternate frequencies can be affected, and the end result is an AP which simply can't find a clean chunk of spectrum in which to transmit, so we have a lot of annoyed customers who are down for a fairly long duration while we scramble to fix it. Dropping to 15.0.2 usually stops the problem, so that is probably the path we'll continue on until we hear otherwise.
I can appreciate your situation, dshea, but unfortunately, if we can't reproduce the problem in our lab, we can't easily fix it without working with our customers who are seeing the issue in the field. As I mentioned before, we haven't had any major changes other than keeping up with regulatory requirements, so I can't say definitively that 16.0.1 will behave better or worse than 15.0.2 for your particular situation.
In the past we've worked with customers directly who were experiencing issues like you describe, and if we didn't find a bug, we at least determined the source of the interference. If you had an old spare AP laying around that you could set up as a guinea pig in an area that experiences issues, I'm sure we could pull useful data off that to find a solution. I'd encourage you to reach out to support about that if you're willing.