We generally run everything through a no-clean process. So most of the products we make never see a cleaning process.
Occasionally we'll have to fix a soldering defect, i.e. a bridge or insufficient solder. This sometimes means we have to use additional flux, and unfortunately, sometimes you have to clean that residue off since it's beyond what no-clean is supposed to be (minimal residues which won't cause a problem). This affects maybe 1 out of 100 boards, if it's even that many. In the case I was talking about, I recently successfully cleaned part of the metal off of a patch antenna by accident during the hand assembly of a prototype, which is how I figured it out... I had made a mess out of a part I was working on, and just wanted it cleaned up. On Wed, Jul 22, 2020 at 8:45 PM Ken Hohhof <af...@kwisp.com> wrote: > I thought the industry had gone to water soluble flux and then to no clean > flux. Unless you’re talking about maybe some alcohol after a manual repair. > > > > *From:* AF <af-boun...@af.afmug.com> *On Behalf Of *Forrest Christian > (List Account) > *Sent:* Wednesday, July 22, 2020 9:25 PM > *To:* AnimalFarm Microwave Users Group <af@af.afmug.com> > *Subject:* Re: [AFMUG] 450i/450m DFS false detect problem solved in later > firmware? > > > > Yes it is. I'm also a bit concerned with a bit of the material > compatibility with the latest patch they've used as they seem to be doing > some sort of metal depositing which is rather easy to 'erase' with a few of > the solvents one normally encounters in an electronics assembly line. It > really doesn't like the flux cleaner we use here as an example. > > > > > > > > On Wed, Jul 22, 2020 at 8:05 PM Chuck McCown <ch...@wbmfg.com> wrote: > > Is the metal of the patch exposed. Even if it is exposed, a thin layer > will not lower the frequency that much. If it was .100” thick then you may > see a significant change, > > Sent from my iPhone > > > > On Jul 22, 2020, at 6:50 PM, Forrest Christian (List Account) < > li...@packetflux.com> wrote: > > > > Actually it is a bare ceramic patch antenna. Look at the top, you're > seeing the side view. > > > > When I got the response last time from the vendor they said they don't > recommend it, and stated several reasons including if I remember correctly > something about changing the dielectric constant in some odd way, detuning > the antenna. We didn't get much farther than that since they didn't have > a good answer about whether this was confined to certain types of coating > or what... > > > > I haven't heard back from them on whether or not the latest modules or not > have the same issues, but I suspect they likely do. > > > > On the other hand, it wouldn't surprise me to find that what they're > concerned about isn't going to change the tuning enough to actually make a > difference, and they're just being overly cautious. > > > > > > On Wed, Jul 22, 2020 at 7:02 AM Chuck McCown <ch...@wbmfg.com> wrote: > > I would not expect a thin layer of conformal to bother the antenna in a > significant way. It might if you were putting it on a bare patch but that > is not the case here. > > Sent from my iPhone > > > > On Jul 22, 2020, at 6:53 AM, Mark Radabaugh <m...@amplex.net> wrote: > > > > > > 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 > > > > <IMG_3364.jpeg> > > > > On Jul 13, 2020, at 10:28 PM, Forrest Christian (List Account) < > 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> 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 > > > > > -- > > - 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 > > > > > -- > > - 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
