On Jul 13, 2020, at 3:19 AM, Forrest Christian (List Account)
<li...@packetflux.com <mailto:li...@packetflux.com>> wrote:
I need to be a bit clearer in that I'm not really sure what
version this customer is running. The question about 15.x
/16.x came from a couple of oldish threads which indicated that
something broke early in 15, and that it still wasn't fixed in
16. But I found that unlikely to still be the case another
year or two on. In these year-and-a-bit old threads, the
report was that one had to go back to very early in 15.x to
"fix" this issue. But like I've said before in this paragraph
- I find this unlikely to still be the case - I just was hoping
to verify that this wasn't a common knowledge issue that DFS was
broken on 16.x.
I know this customer has been in contact with Cambium. Based
on our conversations with the customer so far, I get the
impression that for some reason they've decided this is a sync
issue. I don't know if this is a customer determination or if
Cambium has told them this. I like your word dubious as I'm
skeptical as well, but I'm also not one to dismiss a possible
cause until I fully rule it out, as they could be 100% correct.
I could see where if you have an AP with sync broken
intermittently (especially if you have freerun on), you might
end up with a DFS event as a result of things just not being in
sync. But I have reason to believe this isn't the case with
any of their AP's - at least not the ones I have seen the GPS
status screen on the RackInjector for.
I could also see where a stray pulse or two may be
misinterpreted by the AP to be the correct alignment and have
the same effect with causing AP to transmit out of sync as
well. But generally, the radios should ignore these as they're
very rare (and exist in both the PacketFlux and official Cambium
gear, so if it's a problem with mine, it should be a problem
with the official gear as well).
And I agree with you 100% about a dislike for DFS. I have a
feeling that this customer isn't going to help me change my opinion.
On Sun, Jul 12, 2020 at 8:23 PM Ken Hohhof <af...@kwisp.com
<mailto:af...@kwisp.com>> wrote:
I am unaware of any correlation between DFS events and
either Packetflux or 15.x FW.
I don’t use a lot of DFS because honestly it seems fussy no
matter what. But I have a tower with 10 sectors in 5 GHz (8
x 450i and 2 x 450m). They are all synced from a Packetflux
Rackinjector using Cambium Sync. 4 of the 450i sectors are
in 5.4 DFS, and I’m embarrassed to find they are still on
15.2 FW. Uptime of about 6 months and no DFS events. So
I’m dubious about all of this.
The latest production FW is 16.2.1 and it also has a lot of
fixes so I’m not sure why you would be running something so
far behind. As I said, I’m embarrassed to find I still have
radios on 15.2.
Has he opened a case with Cambium support? There are some
best practices with DFS. For sure you don’t want to
configure the AP to think the antenna gain is lower than it
is (not possible with 450m or integrated 450i). You don’t
want to set the SM Receive Target Level higher than
necessary on other sectors. Then there’s choosing the
alternate frequencies. And I suppose a poor sync
configuration could cause false DFS detections, where an AP
sees the signal from an adjacent AP.
But who knows what causes these events? Somebody’s Linksys
reflected off a bird? A competitor aiming a new radio? I
used to have a 5.4 GHz PTP500 backhaul and the end pointed
in the general direction of Chicago would have DFS events
when there were storms. I thought ducting was causing it to
see distant signals, but it could also have been tripped by
lightning. DFS is fussy. I don’t like it. If I could swap
out all the SMs on those DFS sectors for 450b, I would
probably move them to U-NII-1.
*From:* AF <af-boun...@af.afmug.com
<mailto:af-boun...@af.afmug.com>> *On Behalf Of *Forrest
Christian (List Account)
*Sent:* Sunday, July 12, 2020 7:56 PM
*To:* AnimalFarm Microwave Users Group <af@af.afmug.com
<mailto:af@af.afmug.com>>
*Subject:* Re: [AFMUG] 450i/450m DFS false detect problem
solved in later firmware?
I read the 16.0.1 release notes, nothing really specific
about DFS other than it being on when it shouldn't be.
However, I agree there is lots of stuff fixed in there, some
of which could have repercussions for DFS.
Are you saying that mid to late 15.x was generally
broken for DFS and this is largely fixed in 16.x? I guess
my real question should have been 'What is the state of DFS
in the 450 platform and how fussy is it'?
I'm still gathering information from this customer but it
sounds like they're still trying to track down the root
cause. Sometime in the past week or so they figured out
that there was some correlation between the DFS events
adding a fair bit of PacketFlux gear, so this correlation is
now the leading root cause in their minds. So now I get to
try to resolve their problem for them.
On Sun, Jul 12, 2020 at 3:00 PM Dave <dmilho...@wletc.com
<mailto:dmilho...@wletc.com>> wrote:
If they are not running 16.0.1 nuthing can help them
from some weird issues with the DFS bands.
Lots of things corrected in 15.2 and later for EIRP and
SNR related calculations the help with H/V misreads and
A/B channel alignments.
Read the release notes in 16.0.1 for further info.
On 7/11/2020 3:12 AM, Forrest Christian (List Account)
wrote:
I'm working with a customer that is having problems
with DFS false hits who is convinced this is a
PacketFlux sync issue. I'm never one to say it
definitively isn't my problem, but I'm skeptical in
this case.
I know that at some point in the past that anything
beyond 15.0.2 was known to have fairly common DFS
issues by some customers. I thought this was
resolved in later releases, but I also don't see any
mention of said issue being resolved in any release
notes post 15.0.02.
I was wondering if anyone knew the current status?
I.E. if they had been seeing the problem previously,
and then discovered it was fixed. Or have tried
recent releases and discovered the problem still
exists, etc...
--
- Forrest
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
- Forrest
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
--
- Forrest
--
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com>
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
