DFS can occur with reflections as well as self interference. Weather
conditions can adverserly affect this.
All things RF for radio config must be set for correct operation IE TX
pwer and Antenna Gains all must be entered to
reflect correct operating levels before a Reflection or interference
issue can be determined.
On 7/13/20 6:56 AM, Mark Radabaugh wrote:
Forrest,
As usual there are probably multiple issues going on. We have seen
an increase in the number of DFS hits recently, and we also have a lot
of Packetflux timing equipment on the network. I have noticed that
DFS hits tend to be worse in ‘unusual’ hot weather conditions. And
we have certainly seen a pretty unusual heat wave over the last few
weeks. I’m not sure if this is just heat changing sensitivity of the
DFS detections (temperature is involved in the RF calibration), if
there is more reflection off the ionosphere in these weather
conditions, or if the weather radar systems are just really jacking up
power looking for storms.
As far as timing - I do think there is some timing instability going
on but I can’t pin it down to anything specific. We continue to
struggle with RackInjectors losing the GPS timing signal from the
Syncbox Basic during or after storm events. Typical symptom in the
RackInjector fails to see sync from the syncbox and the AP’s go into
freerun. Sat’s in view, etc. all look normal, just no pulses.
Sometimes a power cycle from the RackInjector will fix it, sometimes
physically unplugging it will fix it, and sometimes you just have to
wait. I have instructed the field crews multiple times to make
absolutely sure they screw in every screw tight on the syncbox but I’m
not 100% sure they are doing that. I have seen at least one come
back to the shop with evidence of water damage to the GPS board at the
top. I would really like to see the extra step of conformal coating
on the boards if there isn’t a reliable way of keeping water off of them.
We have also been seeing an unusual number of LBT issues with the 3.65
gear which I believe are related to other AP’s drifting or briefly
going off timing.
Due to the number of times we were seeing loss of sync we had to
enable sync + freerun in order to avoid session resets. I’m not
convinced that we are not still seeing timing jumps due to the
sequence of loss of sync, into freerun, then an abrupt change in
framing when sync comes back. Any time something like that happens
it tends to cause a wave of DFS and LBT events across the network. I
can’t necessarily show anything specific at this point though. We
do get a lot of archived and searchable logging from our Sumologic
syslog server. I’m going to ask the NOC to put together a report of
AP’s reporting timing recovery and any correlation with DFS or LBT
events within a 60 second window and see what we get.
Mark
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
--
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com
