DFS has been a major pain since 15.x. Setting the configuration parameters correctly does not make any difference in DFS false positives. We have a site that once DFS triggers, it will continue to trigger over and over again until you power cycle it. Even then, that is only a temporary fix until another DFS event happens. I understand that Cambium must conform to FCC standards but their DFS algorithm is overly sensitive for sure. I don't believe it matters what sync device you have, DFS will trigger regardless. We've had DFS troubles with CTM's, RackInjectors, CMM4's and uGPS.
Forest, we also have GPS issues similar to Mark's. RackInjector with junior syncbox. AP's will randomly switch sync sources. This doesn't happen on AP's with CTM2's on the same site. I would really like to see the RackInjector provide a temporarily generated sync pulse on the event that GPS actually does fail. This would prevent SM's from re-registering. On Mon, Jul 13, 2020 at 8:44 AM dave <[email protected]> wrote: > > 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) < > [email protected]> 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 <[email protected]> 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 <[email protected]> *On Behalf Of *Forrest Christian >> (List Account) >> *Sent:* Sunday, July 12, 2020 7:56 PM >> *To:* AnimalFarm Microwave Users Group <[email protected]> >> *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 <[email protected]> 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 >> [email protected] >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> >> >> >> >> -- >> >> - Forrest >> -- >> AF mailing list >> [email protected] >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> > > > -- > - Forrest > -- > AF mailing list > [email protected] > http://af.afmug.com/mailman/listinfo/af_af.afmug.com > > > > > -- > AF mailing list > [email protected] > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list [email protected] http://af.afmug.com/mailman/listinfo/af_af.afmug.com
