This one was Chemtronics "Kon Form" SR. Came from Allied Electronics:
Mark > On Jul 22, 2020, at 10:01 AM, Ken Hohhof <af...@kwisp.com> wrote: > > Out of curiosity, what conformal coating did you use? > > Way back in the 1975 timeframe I remember using a spray-on urethane product > from a company named Humiseal or maybe that was the product name, I don’t > know if they still exist. I remember having to mask off the edge connector. > I don’t remember why I was doing this, since I was designing inhouse test > equipment for a company that made TV sets. > > I do remember cost was such a big deal the products (not our test equipment) > used single-sided paper based phenolic PCBs and the leads weren’t trimmed on > the bottom side of the board, they stuck out like a porcupine. PCB layouts > left as much copper on the board as possible to save on ferric chloride > etching solution. We tested everything literally hot off the production line > to minimize rework cost if a problem was found. > > > From: AF <af-boun...@af.afmug.com> On Behalf Of Mark Radabaugh > Sent: Wednesday, July 22, 2020 7:53 AM > To: AnimalFarm Microwave Users Group <af@af.afmug.com> > Subject: Re: [AFMUG] 450i/450m DFS false detect problem solved in later > firmware? > > > I decided to try a conformal coating on the Syncbox to see if it would cause > any problems with the GPS and avoid the corrosion issues we have seen. We > tested before and after the conformal coating with no detectable impairment > to the GPS SNR and signal level. > > Only about 16 hours so far but throwing a pitcher of water on it and leaving > the cover off all night in a rainstorm hasn’t seemed to bother it. The > picture didn’t catch the sync light but it’s happily blinking away. There is > a lot of silicon grease on/around the RJ45 which looks a bit funny but I > can’t conformal coat the jack itself for obvious reasons and I was intending > to douse this one with water. I’m sure SNR is bad right now with a blob of > water on top of the antenna but it’s picking up enough to stay in lock. > > Going to leave it like this and give it a couple weeks to see how it holds > up, but so far so good. > > Regarding loss of sync on 450 equipment - on further examination of the logs > we are seeing issues with 450 equipment randomly losing sync or switching to > free-run and back to sync-over-power across a number of injectors - CMM5, > CTM-2, and Rackinjectors. These issues started about the time we started > deploying SyncInjectors but it’s really looking like that is coincidental. > Data is pointing toward something that changed with the firmware rather than > the injector. I have not had time yet to see if it included the older 450 > versus 450i yet. > > Mark > > <image001.jpg> > > >> On Jul 13, 2020, at 10:28 PM, Forrest Christian (List Account) >> <li...@packetflux.com <mailto:li...@packetflux.com>> wrote: >> >> You bring up a few fair, and known, points. I'll respond to at least a few >> of them: >> >> In relation to the water ingress, we've seen enough of these to know it's at >> least an occasional issue. Especially in hotter climates, one thing we've >> seen is the gasket cracking in the enclosure. I'm also not completely >> convinced this isn't a water condensation/surface moisture issue in damper >> climates. Our enclosure manufacture just switched the gasketing material, >> perhaps as a result of our whining, to something different. I've also >> looked at various alternatives for enclosures but haven't found the right >> one yet. I thought I had one which would have been perfect, until I got >> the $50 per unit quote in quantity. Some days I miss the pipes, but it was >> time for them to go from a mostly marketing perspective. >> >> I've also looked at the conformal coating in the past, and the challenge has >> been that the GPS module manufacture has told us this is a no-no since it >> apparently changes the tuning of the GPS patch antenna. I probably need to >> re-evaluate this now that there's a different patch antenna on the new >> modules - but I expect a similar answer. >> >> For the past couple of years, I've been trying to move to a module flat on >> the board and then either using a PCB antenna like is used in devices like >> cell phones, where the antenna's pattern is such that mounting it flat on >> vertically oriented PCB results in a vertical pattern like the patch has. >> This should solve the water getting on the antenna issue, as there won't be >> anything directly below the seam to leak on. The holdup has been me >> trying to possibly move to a module with a different GPS chipset at the same >> time, hoping that this would be better than our existing module. With all >> the warts (some of which will be described below), I'm finding that the >> modules/chipset that we're using is actually not that bad in comparison to >> some others. I even have had an eval of a 'timing grade' gps receiver >> here, which had more failures than the non-timing-grade ones we're using. I >> have a few more to qualify, but look for this change in coming months >> assuming I can find a suitable module and antenna which works. >> >> In relation to the random timing loss of lock, I am not going to disagree >> with you at all. I suspect some of this might be leftovers from the >> GPS+GLONASS issue from the end of the year which seems to have resolved >> itself for the most part, but I know enough about that bug that it wouldn't >> shock me to find that there are still lingering issues. The problem here >> is that although it 'feels' like there might be more issues, I don't have >> quantifiable numbers. With all of that in mind, I'm currently working on >> in-field upgrade procedures for upgrading the firmware for these modules to >> get them the GLONASS fix. This seems to be a more troublesome problem than >> it should be, since it's just an issue of getting the right firmware - the >> problem being that the company who built the firmware for these got gobbled >> and the successor company tends to be more difficult to work with. I have >> firmware which does work on the modules, it just isn't an official build by >> the manufacturer. >> >> Around the end of the year, we did switch our basics to a newer module, >> based on the same chipset. The Basics shipped since then default to >> GPS+GALILEO. Recently we've been using this module in Aux Port and >> Deluxes, but with GPS+GLONASS+Fixed-Glonass firmware since the Cambium >> firmware doesn't understand (yet) the Galileo sentences. So anything you >> get from us today has this latest chipset in it, and has the GLONASS fix >> even if it isn't enabled. I will say that testing and in-field reports >> indicates this is even more stable, not sure how much of it is because of >> the increased antenna gain, and how much of it is due to the updated >> firmware, or how much is just a side effect of having a lot more of the >> older units in the field having customers report problems on. I know at >> least some of it is measurable on the bench here, so it isn't all based on >> field reports. The only downside so far is that we do see an uptick in >> DoA's (but still well under 1%). Frustratingly, the DoA's we've gotten back >> have somehow resurrected themselves between the field and here, but >> thankfully there doesn't seem to be any increased in-field failures that we >> can see other than the DoA's. >> >> To Eric's point about the holdover timer.. I understand the CTM2's had >> this functionality built in. Nothing else I'm aware of has had that except >> for some our early GPS modules which just produced a pulse no matter what, >> and when it could align it it would. This was good in the early days, not >> so much nowadays. >> >> I'm looking at a couple options to implement a holdover. First of all, >> assuming the docs are correct, I can tell the GPS modules to produce sync >> all the time, or only when they have a 2D lock, or when they have a 3d lock. >> Sync all the time can be bad. Especially if you're not monitoring lock >> status, since it means that a GPS can be out of lock but producing sync >> pulses which are wildly wrong, causing all sorts of issues. 2d lock can be >> bad too since it shares similar issues. As a result, the modules default >> to '3d lock'. I've been toying with doing something dynamic in the >> rackinjector where it is able to dynamically changes the mode, so it waits >> until you get 3d lock, and then since it should have a good position, >> switches to '2d lock' mode, or maybe even freerun. At the bare minimum, I >> probably will allow customers to change the setting statically if they're >> willing to deal with the ramifications. >> >> I have some other ideas I'm cooking up as well, just don't want to say too >> much until I'm actually a bit farther down the path. >> >> >> On Mon, Jul 13, 2020 at 5:57 AM Mark Radabaugh <m...@amplex.net >> <mailto:m...@amplex.net>> 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 >>>>>> <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 >>>>> <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 >>>> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >>> >>> -- >>> AF mailing list >>> AF@af.afmug.com <mailto:AF@af.afmug.com> >>> http://af.afmug.com/mailman/listinfo/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 >> <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
