Cambium owes you a consulting retainer. Sent from my iPhone
> On Jul 13, 2020, at 6:38 PM, Forrest Christian (List Account) > <li...@packetflux.com> wrote: > > > So I replied to part of your comment in my last email... > > I had another phone call with the customer and Cambium together. In > deference to Cambium and the customer, as we work through these issues I > won't go into a lot of details, but this definitely seems to me like there's > a good chance that this is going to result in an improvement to a lot of the > things which we're whining about in the thread. If my suspicions are true > about the mechanism at work here, I could see where many of described > misbehaviors of DFS would neatly be described by this. And no, thankfully, > this doesn't seem to be a PacketFlux-specific issue, although I can see how > questionable sync out of any device might trigger this... > > >> On Mon, Jul 13, 2020 at 8:37 AM Eric Muehleisen <ericm...@gmail.com> wrote: >> 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 <dmilho...@wletc.com> 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. >>> >>> >>> <Vcard.jpg> >>> 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> 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> 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> On Behalf Of Forrest Christian (List >>>>>> Account) >>>>>> Sent: Sunday, July 12, 2020 7:56 PM >>>>>> To: AnimalFarm Microwave Users Group <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> 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 >>>>>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> - Forrest >>>>>> >>>>>> -- >>>>>> AF mailing list >>>>>> AF@af.afmug.com >>>>>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >>>>> >>>>> >>>>> -- >>>>> - Forrest >>>>> -- >>>>> AF mailing list >>>>> 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 >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com > > > -- > - Forrest > -- > AF mailing list > 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
