Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Forrest Christian (List Account)
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 

Re: [AFMUG] OT new splicing trailer

2020-07-13 Thread Jon Langeler
Does anyone know? Do splice trailers get grounded for reasons of generator 
and/or other reasons while splicing? 

Jon Langeler
Michwave Technologies, Inc.


> On Jun 23, 2020, at 4:45 PM, ch...@wbmfg.com wrote:
> 
> 
> It is double walled, with mineral blankets. 
> But nothing suspended.  Just trying to not interrupt sleep in residential 
> neighborhoods during night cuts. 
> Work in progress.  We will build another one for our other splice trailer 
> once we work out the kinks.
>  
> Like to be 60 dB at 10 feet. 
>  
> From: castarritt .
> Sent: Tuesday, June 23, 2020 2:04 PM
> To: AnimalFarm Microwave Users Group
> Subject: Re: [AFMUG] OT new splicing trailer
>  
> Neat project.  Have you considered making it double walled with some sort of 
> anti-vibration material or suspension between the inner and outer layers?
>  
> On Tue, Jun 23, 2020 at 1:01 PM Chuck McCown  wrote:
>> And experimental noise control box for the generator.  Getting 10 dB 
>> reduction does far.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone-- 
>> 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
-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Chuck McCown
Cambium owes you a consulting retainer.

Sent from my iPhone

> On Jul 13, 2020, at 6:38 PM, Forrest Christian (List Account) 
>  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  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  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 

Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Forrest Christian (List Account)
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  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  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) <
>> li...@packetflux.com> wrote:
>>
>> I need to be a bit clearer in that I'm not really sure what version this
>> 

Re: [AFMUG] OT..damn doctor...no pirate patches in stock..

2020-07-13 Thread James Howard
It's Odin!

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Jaime Solorza
Sent: Monday, July 13, 2020 5:20 PM
To: AnimalFarm Microwave Users Group 
Subject: [AFMUG] OT..damn doctor...no pirate patches in stock..

Headed home

Total Control Panel

Login


To: 
ja...@litewire.net

From: af-boun...@af.afmug.com





You received this message because the domain afmug.com is on your allow list.



-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] Contact for Calix

2020-07-13 Thread Cory Polman
Hey Chuck…I’m on it!

Paul I forwarded your email on to Brendon he’ll be reaching out.

Thanks!

Cory

Cory L Polman
Vice President Sales – Regional West
Calix
email cory.pol...@calix.com

[signature_2038125145]


From: AF  On Behalf Of ch...@wbmfg.com
Sent: Monday, July 13, 2020 4:56 PM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] Contact for Calix

Cory, are you here?

From: Paul McCall
Sent: Monday, July 13, 2020 3:30 PM
To: AnimalFarm Microwave Users Group
Subject: [AFMUG] Contact for Calix

Anybody have a reliable inside contact for Calix (pre-sales tech).  We really 
want to look at their product, have left several web inquiries , emailed a 
couple folks we found on the web over the past couple months and …. Crickets.

Are they still doing business?

Paul

Paul McCall, President
Florida Broadband / PDMNet
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800


--
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


Re: [AFMUG] OT..damn doctor...no pirate patches in stock..

2020-07-13 Thread chuck
https://www.youtube.com/watch?v=uRe0FDvFRtM

From: Jaime Solorza 
Sent: Monday, July 13, 2020 4:20 PM
To: AnimalFarm Microwave Users Group 
Subject: [AFMUG] OT..damn doctor...no pirate patches in stock..

Headed home



-- 
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


Re: [AFMUG] OT..damn doctor...no pirate patches in stock..

2020-07-13 Thread Jaime Solorza
Great idea

On Mon, Jul 13, 2020, 4:29 PM Bill Prince  wrote:

> Maybe you can stop at the 5 and dime to snab a Halloween pirate costume.
> Those include an eye patch.
>
>
> bp
> 
>
>
> On 7/13/2020 3:20 PM, Jaime Solorza wrote:
>
> Headed home
>
> --
> 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


Re: [AFMUG] OT..damn doctor...no pirate patches in stock..

2020-07-13 Thread Bill Prince

  
  
Maybe you can stop at the 5 and dime to snab a Halloween pirate
  costume. Those include an eye patch.


bp



On 7/13/2020 3:20 PM, Jaime Solorza
  wrote:


  
  Headed home
  
  

  


-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] Contact for Calix

2020-07-13 Thread chuck
Cory, are you here?

From: Paul McCall 
Sent: Monday, July 13, 2020 3:30 PM
To: AnimalFarm Microwave Users Group 
Subject: [AFMUG] Contact for Calix

Anybody have a reliable inside contact for Calix (pre-sales tech).  We really 
want to look at their product, have left several web inquiries , emailed a 
couple folks we found on the web over the past couple months and …. Crickets.

 

Are they still doing business?

 

Paul

 

Paul McCall, President 

Florida Broadband / PDMNet

658 Old Dixie Highway

Vero Beach, FL 32962

772-564-6800

 




-- 
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


Re: [AFMUG] Contact for Calix

2020-07-13 Thread Darin Steffl
I emailed you over a guy to talk to at Calix if you're not hearing anything
back.

On Mon, Jul 13, 2020 at 4:31 PM Paul McCall  wrote:

> Anybody have a reliable inside contact for Calix (pre-sales tech).  We
> really want to look at their product, have left several web inquiries ,
> emailed a couple folks we found on the web over the past couple months and
> …. Crickets.
>
>
>
> Are they still doing business?
>
>
>
> Paul
>
>
>
> *Paul McCall, President *
>
> *Florida Broadband / PDMNet*
>
> *658 Old Dixie Highway*
>
> *Vero Beach, FL 32962*
>
> *772-564-6800*
>
>
> --
> AF mailing list
> AF@af.afmug.com
> http://af.afmug.com/mailman/listinfo/af_af.afmug.com
>


-- 
Darin Steffl
Minnesota WiFi
www.mnwifi.com
507-634-WiFi
 Like us on Facebook

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


[AFMUG] Contact for Calix

2020-07-13 Thread Paul McCall
Anybody have a reliable inside contact for Calix (pre-sales tech).  We really 
want to look at their product, have left several web inquiries , emailed a 
couple folks we found on the web over the past couple months and  Crickets.

Are they still doing business?

Paul

Paul McCall, President
Florida Broadband / PDMNet
658 Old Dixie Highway
Vero Beach, FL 32962
772-564-6800

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] Two SiteMonitor unresponsive

2020-07-13 Thread Steve Jones
i use an old dumb 5 port switch between pc and sitemonitor  to get to them
for initial programming

On Wed, Jul 8, 2020 at 2:50 PM Josh Luthman 
wrote:

> I did disable the other interfaces.  Had 10 half link to my laptop.  Got
> link light on a dumb switch.  I would still think it'd be 169.254.1.20/16
> on new devices, which doesn't ping or arp.
>
> Turned off firewall and ran the program as admin.  Discover IP worked!  I
> told it to factory reset, power cycled it, and now I can get in to it!
> Thanks for the tip.
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Wed, Jul 8, 2020 at 2:12 PM Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
>> The reset process uses multicast.   The challenge with multicast is that
>> Windows seems to be non-consistent about what interface it sends the
>> multicast messages out on.  Sometimes it's all of them.  Sometimes it's at
>> least the active ethernet.   But for some reason, a certain (high)
>> percentage of devices will decide to send them on some random,
>> not-even-in-use interface.  And there doesn't seem (in at least the tools
>> we're using) any way to force it ou a given interface.
>>
>> So yes, disabling all the unused interfaces is useful.Also running
>> the tool as administrator also sometimes helps.  Plus disabling the windows
>> (or other) firewall.  Plus you'll find the odd switch/device which doesn't
>> really do 10Mb/s anymore.  Those are probably the biggest causes.
>>
>> The Base 3/Rackinjector uses a different, probably just as annoying,
>> method of resetting the units.
>>
>> On Wed, Jul 8, 2020 at 10:12 AM Bill Prince  wrote:
>>
>>> I found that I had to use a PC with only one interface active to make
>>> the factory reset work. I don't know if it was me, or that he reset
>>> software needed a dedicated interface to work its process.
>>>
>>>
>>> bp
>>> 
>>>
>>>
>>> On 7/8/2020 9:05 AM, Josh Luthman wrote:
>>>
>>> I have two units (ii "newer" ones) that I can't get to 169.254.1.20.
>>> Several laptops, several network cables, switches, etc later.
>>>
>>> They've been on the shelf for years unpowered.  Maybe both were DOA, but
>>> I feel like that's unlikely.
>>>
>>> I tried to factory reset one with the software @
>>> https://tickets.packetflux.com/kb/faq.php?id=13 but that didn't work.
>>> That never has worked for me, I don't think.
>>>
>>> Does anyone have any ideas before I just buy a couple more?
>>>
>>> Josh Luthman
>>> Office: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>>
>>> --
>>> 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


Re: [AFMUG] American Girl Karen doll

2020-07-13 Thread Steve Jones
we have achieved a level of legislative dumb that I dont think even
southpark could ever have imagined

On Wed, Jul 8, 2020 at 11:05 AM Bill Prince  wrote:

> Is it Karen or is it CAREN?
>
>
> https://www.mercurynews.com/2020/07/07/san-francisco-supervisor-introducing-caren-act-to-stop-racist-9-1-1-calls/
>
>
> bp
> 
>
> On 7/8/2020 8:51 AM, Jay Weekley wrote:
> > I feel sorry for people actually named Karen.
> >
> > Ken Hohhof wrote:
> >>
> >> https://www.dailydot.com/unclick/american-girl-karen-doll-parody/
> >>
> >>
> >>
> >
>
> --
> 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


Re: [AFMUG] OT : Getting more formal in my old age

2020-07-13 Thread chuck
The moral of the story is to be slow to hire and quick to fire.
Life is too short to put with a PITA employee.  
And in the end you may be doing them a favor by firing them.  

From: James Howard 
Sent: Monday, July 13, 2020 1:41 PM
To: 'AnimalFarm Microwave Users Group' 
Subject: Re: [AFMUG] OT : Getting more formal in my old age

Come on now Chuck.  This is very clearly all your fault for not getting a bunch 
of extra keys.  He shouldn’t have had to worry about returning a key after he 
used that truck.  They should be disposable.  How can you expect anyone to have 
a good work ethic or attitude if you don’t provide them with disposable keys 
and their choice of anywhere on your property to park?

 

(sarcasm off now.  In case it wasn’t painfully obvious that it was on…..)

 

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Lewis Bergman
Sent: Monday, July 13, 2020 2:29 PM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] OT : Getting more formal in my old age

 

People...I hate them.

 

On Mon, Jul 13, 2020 at 12:59 PM  wrote:

  This is what I do now every time we fire someone.  

   

  They always apply for benefits it seems.  There is always a hearing.

  We win the hearings but it is a PITA...

   

  After this I went out and appologized to the crew that witnessed it.  It has 
been years since I lost my cool like that.  They were all seemingly delighted 
that the guy is now gone.

  In all my years of firing people, many dozens, perhaps as many as 100, only 1 
was a situation where I regretted it afterwards.  The guy was following along 
with some dishonest activity by a coworker and did not stand up to him.  He 
truly did not deserve to lose his job.  All the rest of them I typically say to 
myself afterwards: “should have done this long ago”.

   

  Also, batting  for having formal disciplinary meetings result in a 
permanent change of behavior.  I guess we do them for evidence in the certain 
to be unemployment benefits hearing...

   

  (BTW, the the tale below, this was a truck we bought at Richie Brothers a 
couple of weeks ago and had not yet got a duplicate key made).

   

  From: ch...@wbmfg.com 

  Sent: Monday, July 13, 2020 11:36 AM

  To:  

  Subject: xxx

   

  Put this in xxx personnel file.  

   

  Thursday last week a company truck was parked here at the company by xxx.  He 
did not put the key back in the key box.  It is the only key we had for that 
truck and that truck is a critical vehicle.

   

  This morning (7/13/2020) a group of employees were out on the back lot 
working on a project and I walked up and asked them who was last to drive the 
red truck.  They indicated it was xxx.  I asked where the key was, he was very 
non committal.  Essentially shrugging his shoulders.  I told him that it must 
be between the truck and the office key box, did he walk that route and look 
for it.  Nope, he said, he went and did some other things after parking the 
truck.  I asked him if he went to those other areas and looked for the key. 
Nope...  Didn’t seem to care.  Had a defiant attitude.  

   

  So I said that in times like these, an owner of the equipment is always happy 
to hear, “hey chuck, sorry, I f**ked up”.  That was met with no response.

  I repeated it a second and third time.  I started laughing and turned to his 
supervisor.  His supervisor xxx said “hey dude, you need to say those words to 
Chuck”.  xxx mumbled some semblance of the phrase but immediately followed it 
with an energetic “you didn’t apologize to me for putting the orange drums 
against my truck”.  

   

  xxx, from day 1 parked first in the bookkeeper’s parking stall, we asked him 
to park out with the other employees.  He then parked in our loading dock 
blocking us from using it.  We had a talk about that.  He finally parked with 
the rest of the employees but on the edge of a drive forcing everyone to swing 
wide around his truck and preventing us from taking larger trucks in that 
parking lot.  I put up some orange construction barrels to block off the area 
where I didn’t want any one to park.  That was OK for a day or two but then I 
came to work and the barrels were in the dirt and xxx had parked on the far end 
again.

   

  I put the barrels in front and to the side of his truck and called his 
supervisor to have him inform xxx that that corner of the parking lot is a no 
park area.

   

  So this morning when xxx defiantly proclaimed that he was owed an apology I 
lost my cool, I told him that it was my parking lot and I could do what I 
wanted.  That in the future he could leave his truck at home and catch a ride 
with someone else.  I also said that he may have just lost his job.  

   

  I came back to the office to cool off.  Called a manager (xxx at 10:20 am) 
that was out sick this morning.  He said that xxx had not changed much since 
our last formal disciplinary meeting, so he is fine for xxx to be gone.  I 
called xxx (at 10:26 am) and told him to 

Re: [AFMUG] OT : Getting more formal in my old age

2020-07-13 Thread James Howard
Come on now Chuck.  This is very clearly all your fault for not getting a bunch 
of extra keys.  He shouldn’t have had to worry about returning a key after he 
used that truck.  They should be disposable.  How can you expect anyone to have 
a good work ethic or attitude if you don’t provide them with disposable keys 
and their choice of anywhere on your property to park?

(sarcasm off now.  In case it wasn’t painfully obvious that it was on…..)

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Lewis Bergman
Sent: Monday, July 13, 2020 2:29 PM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] OT : Getting more formal in my old age

People...I hate them.

On Mon, Jul 13, 2020 at 12:59 PM mailto:ch...@wbmfg.com>> 
wrote:
This is what I do now every time we fire someone.

They always apply for benefits it seems.  There is always a hearing.
We win the hearings but it is a PITA...

After this I went out and appologized to the crew that witnessed it.  It has 
been years since I lost my cool like that.  They were all seemingly delighted 
that the guy is now gone.
In all my years of firing people, many dozens, perhaps as many as 100, only 1 
was a situation where I regretted it afterwards.  The guy was following along 
with some dishonest activity by a coworker and did not stand up to him.  He 
truly did not deserve to lose his job.  All the rest of them I typically say to 
myself afterwards: “should have done this long ago”.

Also, batting  for having formal disciplinary meetings result in a 
permanent change of behavior.  I guess we do them for evidence in the certain 
to be unemployment benefits hearing...

(BTW, the the tale below, this was a truck we bought at Richie Brothers a 
couple of weeks ago and had not yet got a duplicate key made).

From: ch...@wbmfg.com
Sent: Monday, July 13, 2020 11:36 AM
To:
Subject: xxx

Put this in xxx personnel file.

Thursday last week a company truck was parked here at the company by xxx.  He 
did not put the key back in the key box.  It is the only key we had for that 
truck and that truck is a critical vehicle.

This morning (7/13/2020) a group of employees were out on the back lot working 
on a project and I walked up and asked them who was last to drive the red 
truck.  They indicated it was xxx.  I asked where the key was, he was very non 
committal.  Essentially shrugging his shoulders.  I told him that it must be 
between the truck and the office key box, did he walk that route and look for 
it.  Nope, he said, he went and did some other things after parking the truck.  
I asked him if he went to those other areas and looked for the key. Nope...  
Didn’t seem to care.  Had a defiant attitude.

So I said that in times like these, an owner of the equipment is always happy 
to hear, “hey chuck, sorry, I f**ked up”.  That was met with no response.
I repeated it a second and third time.  I started laughing and turned to his 
supervisor.  His supervisor xxx said “hey dude, you need to say those words to 
Chuck”.  xxx mumbled some semblance of the phrase but immediately followed it 
with an energetic “you didn’t apologize to me for putting the orange drums 
against my truck”.

xxx, from day 1 parked first in the bookkeeper’s parking stall, we asked him to 
park out with the other employees.  He then parked in our loading dock blocking 
us from using it.  We had a talk about that.  He finally parked with the rest 
of the employees but on the edge of a drive forcing everyone to swing wide 
around his truck and preventing us from taking larger trucks in that parking 
lot.  I put up some orange construction barrels to block off the area where I 
didn’t want any one to park.  That was OK for a day or two but then I came to 
work and the barrels were in the dirt and xxx had parked on the far end again.

I put the barrels in front and to the side of his truck and called his 
supervisor to have him inform xxx that that corner of the parking lot is a no 
park area.

So this morning when xxx defiantly proclaimed that he was owed an apology I 
lost my cool, I told him that it was my parking lot and I could do what I 
wanted.  That in the future he could leave his truck at home and catch a ride 
with someone else.  I also said that he may have just lost his job.

I came back to the office to cool off.  Called a manager (xxx at 10:20 am) that 
was out sick this morning.  He said that xxx had not changed much since our 
last formal disciplinary meeting, so he is fine for xxx to be gone.  I called 
xxx (at 10:26 am) and told him to tell xxx to clock out and go home.  We then 
decided to make this permanent.

From day one xxx was aloof.  Telling his co-workers he knew more about our 
business than we did.  One of our employees quickly asked to to be paired up 
with xxx.  We never asked for specifics.  It may have some racial tension.  xxx 
would refuse to sit at the table when we had company meetings.  He would show 
up late and either not come into 

Re: [AFMUG] OT : Getting more formal in my old age

2020-07-13 Thread Lewis Bergman
People...I hate them.

On Mon, Jul 13, 2020 at 12:59 PM  wrote:

> This is what I do now every time we fire someone.
>
> They always apply for benefits it seems.  There is always a hearing.
> We win the hearings but it is a PITA...
>
> After this I went out and appologized to the crew that witnessed it.  It
> has been years since I lost my cool like that.  They were all seemingly
> delighted that the guy is now gone.
> In all my years of firing people, many dozens, perhaps as many as 100,
> only 1 was a situation where I regretted it afterwards.  The guy was
> following along with some dishonest activity by a coworker and did not
> stand up to him.  He truly did not deserve to lose his job.  All the rest
> of them I typically say to myself afterwards: “should have done this long
> ago”.
>
> Also, batting  for having formal disciplinary meetings result in a
> permanent change of behavior.  I guess we do them for evidence in the
> certain to be unemployment benefits hearing...
>
> (BTW, the the tale below, this was a truck we bought at Richie Brothers a
> couple of weeks ago and had not yet got a duplicate key made).
>
> *From:* ch...@wbmfg.com
> *Sent:* Monday, July 13, 2020 11:36 AM
> *To:*
> *Subject:* xxx
>
> Put this in xxx personnel file.
>
> Thursday last week a company truck was parked here at the company by xxx.
> He did not put the key back in the key box.  It is the only key we had for
> that truck and that truck is a critical vehicle.
>
> This morning (7/13/2020) a group of employees were out on the back lot
> working on a project and I walked up and asked them who was last to drive
> the red truck.  They indicated it was xxx.  I asked where the key was, he
> was very non committal.  Essentially shrugging his shoulders.  I told him
> that it must be between the truck and the office key box, did he walk that
> route and look for it.  Nope, he said, he went and did some other things
> after parking the truck.  I asked him if he went to those other areas and
> looked for the key. Nope...  Didn’t seem to care.  Had a defiant attitude.
>
> So I said that in times like these, an owner of the equipment is always
> happy to hear, “hey chuck, sorry, I f**ked up”.  That was met with no
> response.
> I repeated it a second and third time.  I started laughing and turned to
> his supervisor.  His supervisor xxx said “hey dude, you need to say those
> words to Chuck”.  xxx mumbled some semblance of the phrase but immediately
> followed it with an energetic “you didn’t apologize to me for putting the
> orange drums against my truck”.
>
> xxx, from day 1 parked first in the bookkeeper’s parking stall, we asked
> him to park out with the other employees.  He then parked in our loading
> dock blocking us from using it.  We had a talk about that.  He finally
> parked with the rest of the employees but on the edge of a drive forcing
> everyone to swing wide around his truck and preventing us from taking
> larger trucks in that parking lot.  I put up some orange construction
> barrels to block off the area where I didn’t want any one to park.  That
> was OK for a day or two but then I came to work and the barrels were in the
> dirt and xxx had parked on the far end again.
>
> I put the barrels in front and to the side of his truck and called his
> supervisor to have him inform xxx that that corner of the parking lot is a
> no park area.
>
> So this morning when xxx defiantly proclaimed that he was owed an apology
> I lost my cool, I told him that it was my parking lot and I could do what I
> wanted.  That in the future he could leave his truck at home and catch a
> ride with someone else.  I also said that he may have just lost his job.
>
> I came back to the office to cool off.  Called a manager (xxx at 10:20 am)
> that was out sick this morning.  He said that xxx had not changed much
> since our last formal disciplinary meeting, so he is fine for xxx to be
> gone.  I called xxx (at 10:26 am) and told him to tell xxx to clock out and
> go home.  We then decided to make this permanent.
>
> From day one xxx was aloof.  Telling his co-workers he knew more about our
> business than we did.  One of our employees quickly asked to to be paired
> up with xxx.  We never asked for specifics.  It may have some racial
> tension.  xxx would refuse to sit at the table when we had company
> meetings.  He would show up late and either not come into the meeting room
> or stand away from the rest of us.
>
> He decided to put a water tank on a truck and drive it over I-80 to a job
> site.  He was not asked to put the tank on, the tank was not put on in a
> safe manner and when queried about it he said that Ben McCown and xxx
> wanted it done.  To the contrary Ben told him not to put the tank on as it
> would not be safe and xxx said that he never talked to xxx about it and
> felt xxx was lying.
>
> We have one formal, signed, disciplinary record in the file covering many
> of these argumentative and attitudinal issues.
> He was 

Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Brian Webster
Strippers and that darn glitter makeup, gets all over everything and doesn’t 
come off……..lol

 

Thank you,

Brian Webster

 

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Cameron Crum
Sent: Monday, July 13, 2020 1:10 PM
To: AnimalFarm Microwave Users Group
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

 

Brian, and strippers...don't forget about strippers.

 

On Mon, Jul 13, 2020 at 11:18 AM Brian Webster  wrote:

I read that you need to wear glitter makeup to create an RF faraday cage for 
your face to stop the 5G and metal strip thing from working……..

 

Somebody please make a video stating that and get it to go viral, would love to 
see the sales spike in glitter makeup and all the people wearing it…. Claire’s 
stores would run out of the stuff and all the 8 year old girls and pageant 
participants will be pissed.

 

Thank you,

Brian Webster

www.wirelessmapping.com

 

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Matt Corcoran
Sent: Monday, July 13, 2020 12:01 PM
To: AnimalFarm Microwave Users Group
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

 

I think my customers would be more concerned with:

 

 

Does the metal strip attract lightning?

 

 

 

  _  

From: AF  on behalf of Mathew Howard 

Sent: Monday, July 13, 2020 11:42 AM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you 

 

Lies! it's obviously only safe to wear masks without metal strips...

 

On Mon, Jul 13, 2020 at 8:40 AM Ken Hohhof  wrote:

https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1

 

-- 
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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread dave

We call that one the Earth to Ground wire.
Typically it turns into a neutral wire when run into a distribution 
panel when its isolated.
At tower sites it typically will tie back into a Ground rod at the meter 
called neutral ground Bond.

EVERYthing at the site will typically bond back to this ground.

Birds ... Well thats just weird :)


On 7/13/20 12:17 PM, Josh Luthman wrote:
I thought the neutral was the unshielded wire between the poles.  
That's how my house is hooked up...


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 12:49 PM Bill Prince > wrote:


There is no neutral on power poles. Just hots. One, two, or three
usually.


bp


On 7/13/2020 9:38 AM, Josh Luthman wrote:

Just standard power like at home.  Not three phase.  It's an FM
radio station.  I would assume the hot is at top and neutral
below, but it's been a while since I've seen it myself. Goes from
HV on the road to the tower's (power/utility) pole with a
transformer/fuse.

Two robins on Saturday.  Starling a few minutes ago.  No nests up
there - maybe that's what they are trying to do?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 12:35 PM mailto:ch...@wbmfg.com>> wrote:

What kind of power line?  Like three phase on a cross arm or
single phase with the hot at the top and neutral down below etc?
Nesting activity?  Seem way late in the year for that.  What
kind of bird?
*From:* Josh Luthman
*Sent:* Monday, July 13, 2020 10:29 AM
*To:* AFMUG
*Subject:* [AFMUG] OT: Birds going crazy?
On Saturday we had a power outage.  Beautiful day.  Towers on
batteries, but after an hour we head up there with a
generator.  Plug it in and we're good to go.  Outage was
caused by a bird on the pole and the fuse popped.
Power company comes by, puts up a new fuse.  Power is back. 
He gets in the truck and drives down the lane, about 50 feet,
and *POP*.  Another bird and fuse. Replaces another.  Good
for a few more hours.
Then this morning - power outage AGAIN.  A third "bird" on
the ground below the fuse.

Obviously something's going on, being it's been three times
in three days when this has never happened since ~2008. 
Maybe someone put peanut oil and the rodents are trading
services?
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


-- 
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




-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


[AFMUG] OT : Getting more formal in my old age

2020-07-13 Thread chuck
This is what I do now every time we fire someone.  

They always apply for benefits it seems.  There is always a hearing.
We win the hearings but it is a PITA...

After this I went out and appologized to the crew that witnessed it.  It has 
been years since I lost my cool like that.  They were all seemingly delighted 
that the guy is now gone.
In all my years of firing people, many dozens, perhaps as many as 100, only 1 
was a situation where I regretted it afterwards.  The guy was following along 
with some dishonest activity by a coworker and did not stand up to him.  He 
truly did not deserve to lose his job.  All the rest of them I typically say to 
myself afterwards: “should have done this long ago”.

Also, batting  for having formal disciplinary meetings result in a 
permanent change of behavior.  I guess we do them for evidence in the certain 
to be unemployment benefits hearing...

(BTW, the the tale below, this was a truck we bought at Richie Brothers a 
couple of weeks ago and had not yet got a duplicate key made).

From: ch...@wbmfg.com 
Sent: Monday, July 13, 2020 11:36 AM
To:  
Subject: xxx

Put this in xxx personnel file.  

Thursday last week a company truck was parked here at the company by xxx.  He 
did not put the key back in the key box.  It is the only key we had for that 
truck and that truck is a critical vehicle.

This morning (7/13/2020) a group of employees were out on the back lot working 
on a project and I walked up and asked them who was last to drive the red 
truck.  They indicated it was xxx.  I asked where the key was, he was very non 
committal.  Essentially shrugging his shoulders.  I told him that it must be 
between the truck and the office key box, did he walk that route and look for 
it.  Nope, he said, he went and did some other things after parking the truck.  
I asked him if he went to those other areas and looked for the key. Nope...  
Didn’t seem to care.  Had a defiant attitude.  

So I said that in times like these, an owner of the equipment is always happy 
to hear, “hey chuck, sorry, I f**ked up”.  That was met with no response.
I repeated it a second and third time.  I started laughing and turned to his 
supervisor.  His supervisor xxx said “hey dude, you need to say those words to 
Chuck”.  xxx mumbled some semblance of the phrase but immediately followed it 
with an energetic “you didn’t apologize to me for putting the orange drums 
against my truck”.  

xxx, from day 1 parked first in the bookkeeper’s parking stall, we asked him to 
park out with the other employees.  He then parked in our loading dock blocking 
us from using it.  We had a talk about that.  He finally parked with the rest 
of the employees but on the edge of a drive forcing everyone to swing wide 
around his truck and preventing us from taking larger trucks in that parking 
lot.  I put up some orange construction barrels to block off the area where I 
didn’t want any one to park.  That was OK for a day or two but then I came to 
work and the barrels were in the dirt and xxx had parked on the far end again.

I put the barrels in front and to the side of his truck and called his 
supervisor to have him inform xxx that that corner of the parking lot is a no 
park area.

So this morning when xxx defiantly proclaimed that he was owed an apology I 
lost my cool, I told him that it was my parking lot and I could do what I 
wanted.  That in the future he could leave his truck at home and catch a ride 
with someone else.  I also said that he may have just lost his job.  

I came back to the office to cool off.  Called a manager (xxx at 10:20 am) that 
was out sick this morning.  He said that xxx had not changed much since our 
last formal disciplinary meeting, so he is fine for xxx to be gone.  I called 
xxx (at 10:26 am) and told him to tell xxx to clock out and go home.  We then 
decided to make this permanent.

>From day one xxx was aloof.  Telling his co-workers he knew more about our 
>business than we did.  One of our employees quickly asked to to be paired up 
>with xxx.  We never asked for specifics.  It may have some racial tension.  
>xxx would refuse to sit at the table when we had company meetings.  He would 
>show up late and either not come into the meeting room or stand away from the 
>rest of us.  

He decided to put a water tank on a truck and drive it over I-80 to a job site. 
 He was not asked to put the tank on, the tank was not put on in a safe manner 
and when queried about it he said that Ben McCown and xxx wanted it done.  To 
the contrary Ben told him not to put the tank on as it would not be safe and 
xxx said that he never talked to xxx about it and felt xxx was lying.  

We have one formal, signed, disciplinary record in the file covering many of 
these argumentative and attitudinal issues.  
He was fired for cause this morning.  
Open insubordination officially but the culmination of a long series of events 
as they usually are.  

11:30 am 7/13/2020-- 
AF mailing 

Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Josh Luthman
Well that would be between the building and pole in the "front yard".

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 1:27 PM Bill Prince  wrote:

> The transmission lines are just the hot legs. Neutral and ground get
> created on the secondary side of any transformers. So the concept of
> neutral and ground is "local".
>
>
> bp
> 
>
>
> On 7/13/2020 10:17 AM, Josh Luthman wrote:
>
> I thought the neutral was the unshielded wire between the poles.  That's
> how my house is hooked up...
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Mon, Jul 13, 2020 at 12:49 PM Bill Prince  wrote:
>
>> There is no neutral on power poles. Just hots. One, two, or three usually.
>>
>>
>> bp
>> 
>>
>>
>> On 7/13/2020 9:38 AM, Josh Luthman wrote:
>>
>> Just standard power like at home.  Not three phase.  It's an FM radio
>> station.  I would assume the hot is at top and neutral below, but it's been
>> a while since I've seen it myself.  Goes from HV on the road to the tower's
>> (power/utility) pole with a transformer/fuse.
>>
>> Two robins on Saturday.  Starling a few minutes ago.  No nests up there -
>> maybe that's what they are trying to do?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>>
>> On Mon, Jul 13, 2020 at 12:35 PM  wrote:
>>
>>> What kind of power line?  Like three phase on a cross arm or single
>>> phase with the hot at the top and neutral down below etc?
>>> Nesting activity?  Seem way late in the year for that.  What kind of
>>> bird?
>>>
>>> *From:* Josh Luthman
>>> *Sent:* Monday, July 13, 2020 10:29 AM
>>> *To:* AFMUG
>>> *Subject:* [AFMUG] OT: Birds going crazy?
>>>
>>> On Saturday we had a power outage.  Beautiful day.  Towers on batteries,
>>> but after an hour we head up there with a generator.  Plug it in and we're
>>> good to go.  Outage was caused by a bird on the pole and the fuse popped.
>>>
>>> Power company comes by, puts up a new fuse.  Power is back.  He gets in
>>> the truck and drives down the lane, about 50 feet, and *POP*.  Another bird
>>> and fuse.  Replaces another.  Good for a few more hours.
>>>
>>> Then this morning - power outage AGAIN.  A third "bird" on the ground
>>> below the fuse.
>>>
>>> Obviously something's going on, being it's been three times in three
>>> days when this has never happened since ~2008.  Maybe someone put peanut
>>> oil and the rodents are trading services?
>>>
>>> Josh Luthman
>>> Office: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>>
>>> --
>>> --
>>> 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
>>
>
> --
> 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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Bill Prince

  
  
The transmission lines are just the hot legs. Neutral and ground
  get created on the secondary side of any transformers. So the
  concept of neutral and ground is "local".


bp



On 7/13/2020 10:17 AM, Josh Luthman
  wrote:


  
  I thought the neutral was the unshielded wire
between the poles.  That's how my house is hooked up...

  

  
  
  Josh Luthman
  Office: 937-552-2340
  Direct: 937-552-2343
  1100 Wayne St
  Suite 1337
  Troy, OH 45373
  


  
  
  
On Mon, Jul 13, 2020 at 12:49
  PM Bill Prince  wrote:


  
There is no neutral on power poles. Just hots. One, two,
  or three usually.


bp



On 7/13/2020 9:38 AM, Josh Luthman wrote:


  

  

  Just standard power like at home.  Not three
phase.  It's an FM radio station.  I would
assume the hot is at top and neutral below, but
it's been a while since I've seen it myself. 
Goes from HV on the road to the tower's
(power/utility) pole with a transformer/fuse.
  
  
  Two robins on Saturday.  Starling a few
minutes ago.  No nests up there - maybe that's
what they are trying to do?
  
  
  Josh Luthman
  Office: 937-552-2340
  Direct: 937-552-2343
  1100 Wayne St
  Suite 1337
  Troy, OH 45373
  


  
  
  
On Mon, Jul 13, 2020
  at 12:35 PM 
  wrote:


  

  
What kind of power line?  Like three phase
  on a cross arm or single phase with the hot at
  the top and neutral down below etc?
Nesting activity?  Seem way late in the
  year for that.  What kind of bird?

  
 

  From: Josh Luthman
  
  Sent: Monday, July 13, 2020
10:29 AM
  To: AFMUG 
  Subject: [AFMUG] OT: Birds
going crazy?

  
   


  On Saturday we had a power
outage.  Beautiful day.  Towers on
batteries, but after an hour we head up
there with a generator.  Plug it in and
we're good to go.  Outage was caused by a
bird on the pole and the fuse popped.
 
Power company comes by, puts up a new
  fuse.  Power is back.  He gets in the
  truck and drives down the lane, about 50
  feet, and *POP*.  Another bird and fuse. 
  Replaces another.  Good for a few more
  hours.
 
Then this morning - power outage
  AGAIN.  A third "bird" on the ground below
  the fuse.
  
  Obviously something's going on, being it's
  been three times in three days when this
  has never happened since ~2008.  Maybe
  someone put peanut oil and the rodents are
  trading services?

  

  
 
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
 

Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Josh Luthman
I thought the neutral was the unshielded wire between the poles.  That's
how my house is hooked up...

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 12:49 PM Bill Prince  wrote:

> There is no neutral on power poles. Just hots. One, two, or three usually.
>
>
> bp
> 
>
>
> On 7/13/2020 9:38 AM, Josh Luthman wrote:
>
> Just standard power like at home.  Not three phase.  It's an FM radio
> station.  I would assume the hot is at top and neutral below, but it's been
> a while since I've seen it myself.  Goes from HV on the road to the tower's
> (power/utility) pole with a transformer/fuse.
>
> Two robins on Saturday.  Starling a few minutes ago.  No nests up there -
> maybe that's what they are trying to do?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Mon, Jul 13, 2020 at 12:35 PM  wrote:
>
>> What kind of power line?  Like three phase on a cross arm or single phase
>> with the hot at the top and neutral down below etc?
>> Nesting activity?  Seem way late in the year for that.  What kind of bird?
>>
>> *From:* Josh Luthman
>> *Sent:* Monday, July 13, 2020 10:29 AM
>> *To:* AFMUG
>> *Subject:* [AFMUG] OT: Birds going crazy?
>>
>> On Saturday we had a power outage.  Beautiful day.  Towers on batteries,
>> but after an hour we head up there with a generator.  Plug it in and we're
>> good to go.  Outage was caused by a bird on the pole and the fuse popped.
>>
>> Power company comes by, puts up a new fuse.  Power is back.  He gets in
>> the truck and drives down the lane, about 50 feet, and *POP*.  Another bird
>> and fuse.  Replaces another.  Good for a few more hours.
>>
>> Then this morning - power outage AGAIN.  A third "bird" on the ground
>> below the fuse.
>>
>> Obviously something's going on, being it's been three times in three days
>> when this has never happened since ~2008.  Maybe someone put peanut oil and
>> the rodents are trading services?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> --
>> --
>> 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
>
-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Cameron Crum
Brian, and strippers...don't forget about strippers.

On Mon, Jul 13, 2020 at 11:18 AM Brian Webster 
wrote:

> I read that you need to wear glitter makeup to create an RF faraday cage
> for your face to stop the 5G and metal strip thing from working……..
>
>
>
> Somebody please make a video stating that and get it to go viral, would
> love to see the sales spike in glitter makeup and all the people wearing
> it…. Claire’s stores would run out of the stuff and all the 8 year old
> girls and pageant participants will be pissed.
>
>
>
> Thank you,
>
> Brian Webster
>
> www.wirelessmapping.com
>
>
>
> *From:* AF [mailto:af-boun...@af.afmug.com] *On Behalf Of *Matt Corcoran
> *Sent:* Monday, July 13, 2020 12:01 PM
> *To:* AnimalFarm Microwave Users Group
> *Subject:* Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill
> you
>
>
>
> I think my customers would be more concerned with:
>
>
>
>
>
> Does the metal strip attract lightning?
>
>
>
>
>
>
> --
>
> *From:* AF  on behalf of Mathew Howard <
> mhoward...@gmail.com>
> *Sent:* Monday, July 13, 2020 11:42 AM
> *To:* AnimalFarm Microwave Users Group 
> *Subject:* Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill
> you
>
>
>
> Lies! it's obviously only safe to wear masks without metal strips...
>
>
>
> On Mon, Jul 13, 2020 at 8:40 AM Ken Hohhof  wrote:
>
>
> https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1
>
>
>
> --
> 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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Adam Moffett
There are a lot of things I don't know, especially about power 
distribution.  I do know there's a neutral coming off the center tap on 
the secondary side of an XFormer.  So there's neutral on the power pole 
at least some of the time.  


On 7/13/2020 12:48 PM, Bill Prince wrote:


There is no neutral on power poles. Just hots. One, two, or three usually.


bp


On 7/13/2020 9:38 AM, Josh Luthman wrote:
Just standard power like at home.  Not three phase.  It's an FM radio 
station.  I would assume the hot is at top and neutral below, but 
it's been a while since I've seen it myself.  Goes from HV on the 
road to the tower's (power/utility) pole with a transformer/fuse.


Two robins on Saturday.  Starling a few minutes ago.  No nests up 
there - maybe that's what they are trying to do?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 12:35 PM > wrote:


What kind of power line?  Like three phase on a cross arm or
single phase with the hot at the top and neutral down below etc?
Nesting activity?  Seem way late in the year for that.  What kind
of bird?
*From:* Josh Luthman
*Sent:* Monday, July 13, 2020 10:29 AM
*To:* AFMUG
*Subject:* [AFMUG] OT: Birds going crazy?
On Saturday we had a power outage. Beautiful day.  Towers on
batteries, but after an hour we head up there with a generator. 
Plug it in and we're good to go.  Outage was caused by a bird on
the pole and the fuse popped.
Power company comes by, puts up a new fuse. Power is back.  He
gets in the truck and drives down the lane, about 50 feet, and
*POP*. Another bird and fuse.  Replaces another.  Good for a few
more hours.
Then this morning - power outage AGAIN.  A third "bird" on the
ground below the fuse.

Obviously something's going on, being it's been three times in
three days when this has never happened since ~2008.  Maybe
someone put peanut oil and the rodents are trading services?
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


-- 
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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Bill Prince

  
  
Call Tippi Hedren!


bp



On 7/13/2020 9:38 AM, Robert wrote:


  
  I believe they made a movie about this in the 50's.  Subject
was covered extensively.   I think the solution was wait it out
and it will go away.
  
  On 7/13/20 9:29 AM, Josh Luthman
wrote:
  
  

On Saturday we had a power outage.  Beautiful
  day.  Towers on batteries, but after an hour we head up there
  with a generator.  Plug it in and we're good to go.  Outage
  was caused by a bird on the pole and the fuse popped.
  
  
  Power company comes by, puts up a new fuse.  Power is
back.  He gets in the truck and drives down the lane, about
50 feet, and *POP*.  Another bird and fuse.  Replaces
another.  Good for a few more hours.
  
  
  Then this morning - power outage AGAIN.  A third "bird"
on the ground below the fuse.

Obviously something's going on, being it's been three times
in three days when this has never happened since ~2008. 
Maybe someone put peanut oil and the rodents are trading
services?
  

  

  
  
  Josh Luthman
  Office: 937-552-2340
  Direct: 937-552-2343
  1100 Wayne St
  Suite 1337
  Troy, OH 45373
  

  



  
  
  
  

  


-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Bill Prince

  
  
There is no neutral on power poles. Just hots. One, two, or three
  usually.


bp



On 7/13/2020 9:38 AM, Josh Luthman
  wrote:


  
  

  

  Just standard power like at home.  Not three phase. 
It's an FM radio station.  I would assume the hot is at
top and neutral below, but it's been a while since I've
seen it myself.  Goes from HV on the road to the tower's
(power/utility) pole with a transformer/fuse.
  
  
  Two robins on Saturday.  Starling a few minutes ago. 
No nests up there - maybe that's what they are trying to
do?
  
  
  Josh Luthman
  Office: 937-552-2340
  Direct: 937-552-2343
  1100 Wayne St
  Suite 1337
  Troy, OH 45373
  


  
  
  
On Mon, Jul 13, 2020 at 12:35
  PM 
  wrote:


  

  
What kind of power line?  Like three phase on a
  cross arm or single phase with the hot at the top and
  neutral down below etc?
Nesting activity?  Seem way late in the year for
  that.  What kind of bird?

  
 

  From: Josh Luthman 
  Sent: Monday, July 13, 2020 10:29 AM
  To: AFMUG 
  Subject: [AFMUG] OT: Birds going
crazy?

  
   


  On Saturday we had a power outage. 
Beautiful day.  Towers on batteries, but after an
hour we head up there with a generator.  Plug it in
and we're good to go.  Outage was caused by a bird
on the pole and the fuse popped.
 
Power company comes by, puts up a new fuse. 
  Power is back.  He gets in the truck and drives
  down the lane, about 50 feet, and *POP*.  Another
  bird and fuse.  Replaces another.  Good for a few
  more hours.
 
Then this morning - power outage AGAIN.  A
  third "bird" on the ground below the fuse.
  
  Obviously something's going on, being it's been
  three times in three days when this has never
  happened since ~2008.  Maybe someone put peanut
  oil and the rodents are trading services?

  

  
 
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

  

  
  
  
  
  -- 
  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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Carl Peterson
5Gs from your tower are messing up the birds chakras.

On Mon, Jul 13, 2020 at 11:46 AM Adam Moffett  wrote:

> Aren't birds sensitive to magnetism because they navigate with the earth's
> magnetic field?  Or is that a myth?  Maybe something about this fuse holder
> causes a navigational issue for the birdies.
>
>
> On 7/13/2020 12:29 PM, Josh Luthman wrote:
>
> On Saturday we had a power outage.  Beautiful day.  Towers on batteries,
> but after an hour we head up there with a generator.  Plug it in and we're
> good to go.  Outage was caused by a bird on the pole and the fuse popped.
>
> Power company comes by, puts up a new fuse.  Power is back.  He gets in
> the truck and drives down the lane, about 50 feet, and *POP*.  Another bird
> and fuse.  Replaces another.  Good for a few more hours.
>
> Then this morning - power outage AGAIN.  A third "bird" on the ground
> below the fuse.
>
> Obviously something's going on, being it's been three times in three days
> when this has never happened since ~2008.  Maybe someone put peanut oil and
> the rodents are trading services?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> --
> 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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Adam Moffett
Aren't birds sensitive to magnetism because they navigate with the 
earth's magnetic field?  Or is that a myth?  Maybe something about this 
fuse holder causes a navigational issue for the birdies.



On 7/13/2020 12:29 PM, Josh Luthman wrote:
On Saturday we had a power outage.  Beautiful day. Towers on 
batteries, but after an hour we head up there with a generator.  Plug 
it in and we're good to go.  Outage was caused by a bird on the pole 
and the fuse popped.


Power company comes by, puts up a new fuse.  Power is back.  He gets 
in the truck and drives down the lane, about 50 feet, and *POP*.  
Another bird and fuse.  Replaces another. Good for a few more hours.


Then this morning - power outage AGAIN.  A third "bird" on the ground 
below the fuse.


Obviously something's going on, being it's been three times in three 
days when this has never happened since ~2008.  Maybe someone put 
peanut oil and the rodents are trading services?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Josh Luthman
Just standard power like at home.  Not three phase.  It's an FM radio
station.  I would assume the hot is at top and neutral below, but it's been
a while since I've seen it myself.  Goes from HV on the road to the tower's
(power/utility) pole with a transformer/fuse.

Two robins on Saturday.  Starling a few minutes ago.  No nests up there -
maybe that's what they are trying to do?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Mon, Jul 13, 2020 at 12:35 PM  wrote:

> What kind of power line?  Like three phase on a cross arm or single phase
> with the hot at the top and neutral down below etc?
> Nesting activity?  Seem way late in the year for that.  What kind of bird?
>
> *From:* Josh Luthman
> *Sent:* Monday, July 13, 2020 10:29 AM
> *To:* AFMUG
> *Subject:* [AFMUG] OT: Birds going crazy?
>
> On Saturday we had a power outage.  Beautiful day.  Towers on batteries,
> but after an hour we head up there with a generator.  Plug it in and we're
> good to go.  Outage was caused by a bird on the pole and the fuse popped.
>
> Power company comes by, puts up a new fuse.  Power is back.  He gets in
> the truck and drives down the lane, about 50 feet, and *POP*.  Another bird
> and fuse.  Replaces another.  Good for a few more hours.
>
> Then this morning - power outage AGAIN.  A third "bird" on the ground
> below the fuse.
>
> Obviously something's going on, being it's been three times in three days
> when this has never happened since ~2008.  Maybe someone put peanut oil and
> the rodents are trading services?
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> --
> --
> 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


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread Robert
I believe they made a movie about this in the 50's.  Subject was covered 
extensively.   I think the solution was wait it out and it will go away.


On 7/13/20 9:29 AM, Josh Luthman wrote:
On Saturday we had a power outage.  Beautiful day. Towers on 
batteries, but after an hour we head up there with a generator.  Plug 
it in and we're good to go.  Outage was caused by a bird on the pole 
and the fuse popped.


Power company comes by, puts up a new fuse.  Power is back.  He gets 
in the truck and drives down the lane, about 50 feet, and *POP*.  
Another bird and fuse.  Replaces another. Good for a few more hours.


Then this morning - power outage AGAIN.  A third "bird" on the ground 
below the fuse.


Obviously something's going on, being it's been three times in three 
days when this has never happened since ~2008.  Maybe someone put 
peanut oil and the rodents are trading services?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373



-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] OT: Birds going crazy?

2020-07-13 Thread chuck
What kind of power line?  Like three phase on a cross arm or single phase with 
the hot at the top and neutral down below etc?
Nesting activity?  Seem way late in the year for that.  What kind of bird?

From: Josh Luthman 
Sent: Monday, July 13, 2020 10:29 AM
To: AFMUG 
Subject: [AFMUG] OT: Birds going crazy?

On Saturday we had a power outage.  Beautiful day.  Towers on batteries, but 
after an hour we head up there with a generator.  Plug it in and we're good to 
go.  Outage was caused by a bird on the pole and the fuse popped. 

Power company comes by, puts up a new fuse.  Power is back.  He gets in the 
truck and drives down the lane, about 50 feet, and *POP*.  Another bird and 
fuse.  Replaces another.  Good for a few more hours.

Then this morning - power outage AGAIN.  A third "bird" on the ground below the 
fuse.

Obviously something's going on, being it's been three times in three days when 
this has never happened since ~2008.  Maybe someone put peanut oil and the 
rodents are trading services?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373



-- 
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


[AFMUG] OT: Birds going crazy?

2020-07-13 Thread Josh Luthman
On Saturday we had a power outage.  Beautiful day.  Towers on batteries,
but after an hour we head up there with a generator.  Plug it in and we're
good to go.  Outage was caused by a bird on the pole and the fuse popped.

Power company comes by, puts up a new fuse.  Power is back.  He gets in the
truck and drives down the lane, about 50 feet, and *POP*.  Another bird and
fuse.  Replaces another.  Good for a few more hours.

Then this morning - power outage AGAIN.  A third "bird" on the ground below
the fuse.

Obviously something's going on, being it's been three times in three days
when this has never happened since ~2008.  Maybe someone put peanut oil and
the rodents are trading services?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Bill Prince

  
  
Subject matter people have no charisma.


bp



On 7/13/2020 8:48 AM, Adam Moffett
  wrote:


  
  I wonder how useful these "debunking" articles are.  The true
conspiracy devotee will believe whatever they want, and anybody
else is just rolling their eyes.
  Although it is a disturbing trend in politics, science, etc
that a lot of people are more willing to believe some friggin
guy on Youtube than subject matter experts. 
  
  
  
  On 7/13/2020 9:39 AM, Ken Hohhof
wrote:
  
  




  https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1
   



  
  
  

  


-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Brian Webster
I read that you need to wear glitter makeup to create an RF faraday cage for
your face to stop the 5G and metal strip thing from working

 

Somebody please make a video stating that and get it to go viral, would love
to see the sales spike in glitter makeup and all the people wearing it..
Claire's stores would run out of the stuff and all the 8 year old girls and
pageant participants will be pissed.

 

Thank you,

Brian Webster

www.wirelessmapping.com

 

From: AF [mailto:af-boun...@af.afmug.com] On Behalf Of Matt Corcoran
Sent: Monday, July 13, 2020 12:01 PM
To: AnimalFarm Microwave Users Group
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

 

I think my customers would be more concerned with:

 

 

Does the metal strip attract lightning?

 

 

 

  _  

From: AF  on behalf of Mathew Howard

Sent: Monday, July 13, 2020 11:42 AM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you 

 

Lies! it's obviously only safe to wear masks without metal strips...

 

On Mon, Jul 13, 2020 at 8:40 AM Ken Hohhof  wrote:

https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fac
t-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1

 

-- 
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


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Matt Corcoran
I think my customers would be more concerned with:


Does the metal strip attract lightning?




From: AF  on behalf of Mathew Howard 

Sent: Monday, July 13, 2020 11:42 AM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

Lies! it's obviously only safe to wear masks without metal strips...

On Mon, Jul 13, 2020 at 8:40 AM Ken Hohhof 
mailto:af...@kwisp.com>> wrote:

https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1



--
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


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread can...@believewireless.net
That absolutely makes sense! It's not Covid killing people, it's 5G! No
wonder they want a requirement for everyone to wear a mask!

On Mon, Jul 13, 2020 at 11:49 AM Adam Moffett  wrote:

> I wonder how useful these "debunking" articles are.  The true conspiracy
> devotee will believe whatever they want, and anybody else is just rolling
> their eyes.
>
> Although it is a disturbing trend in politics, science, etc that a lot of
> people are more willing to believe some friggin guy on Youtube than subject
> matter experts.
>
>
> On 7/13/2020 9:39 AM, Ken Hohhof wrote:
>
>
> https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1
>
>
>
> --
> 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


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Adam Moffett
I wonder how useful these "debunking" articles are.  The true conspiracy 
devotee will believe whatever they want, and anybody else is just 
rolling their eyes.


Although it is a disturbing trend in politics, science, etc that a lot 
of people are more willing to believe some friggin guy on Youtube than 
subject matter experts.



On 7/13/2020 9:39 AM, Ken Hohhof wrote:


https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1


-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Mathew Howard
Lies! it's obviously only safe to wear masks without metal strips...

On Mon, Jul 13, 2020 at 8:40 AM Ken Hohhof  wrote:

>
> https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fact-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1
>
>
> --
> 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


Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Adam Moffett
If a software bug accidentally made DFS way less sensitive I don't think 
anyone would complain.


FEATURE REQUEST: A plausibly deniable DFS bug.


On 7/13/2020 10:37 AM, Eric Muehleisen 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 > 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)
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

Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Eric Muehleisen
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  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) <
> 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 

Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread dave


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) 
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 

[AFMUG] no, metal strip in mask is not 5G antenna to kill you

2020-07-13 Thread Ken Hohhof
https://www.reuters.com/article/uk-factcheck-metal-strip-medical-masks-5/fac
t-check-metal-strip-in-medical-masks-is-not-a-5g-antenna-idUSKBN24A2O1

 

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Ken Hohhof
Many many years ago (in the FSK days) I remember a sync problem that was 
affecting VoIP customers, and we only tracked it down by graphing the 
InSyncCount and OutSyncCount SNMP parameters on the SMs.  This would have been 
with a CTM-1 for sync, unfortunately I don’t remember what was the cause and 
the fix.  Something about the AP suddenly shifting its timing probably.

 

 

From: AF  On Behalf Of Mark Radabaugh
Sent: Monday, July 13, 2020 6:57 AM
To: AnimalFarm Microwave Users Group 
Subject: Re: [AFMUG] 450i/450m DFS false detect problem solved in later 
firmware?

 

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) 
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 

Re: [AFMUG] tomorrow

2020-07-13 Thread Lewis Bergman
Are you sure this was meant for the AF group?

On Sun, Jul 12, 2020 at 2:50 PM  wrote:

> Excellent job on the intersection guys.  Y’all just keep getting better at
> what you do.
>
> This week Centracom said they are coming to splice and perhaps install
> equipment in the C.O.
> BTW, C.O. stands for Central Office.  Many years ago it was CDO for
> Central Distribution Office.  This is where the telephone operators used to
> manually switch telephone calls with “cord boards”.  Later automatic
> switching equipment took over that job but the C.O. has remained.  Internet
> companies frequently call their main tech office the NOC Network Operations
> Center.  NOC is probably taking over for C.O. but I am an older dude and
> will continue to refer to the C.O.  Ours is so small it would more properly
> be called a Carrier Hut or Remote.  But I digress.
>
> We want everything looking as nice as we can for our upstream provider’s
> visit.
>
> Inside the C.O. we need the following done:
> Racks straightened
> Batteries reversed
> Walls and ceiling washed
> Stairs installed
> Unused wires and equipment removed
> Wires straightened up and dressed better
> Perhaps run the 120 VAC to the inverter input
>
> Outside the C.O. we need the following:
> Back wall painted where the ducts are.
> Box that was over that area removed from the field to the North and either
> saved for repurpose or put in the scrap metal dumpster.
> All weeds removed from the fenced area.
> Gravel covering 100% of that area.
>
> Outside the fenced area we need the following:
> Put all the pieces of that motorhome in the dump trailer.  Any other
> garbage too and take it to the dump.
> Move that motorhome chassis somewhere it is not obvious.
> Clean up, straight up etc the lot.  Make sure all the trucks and such are
> parked in a nice orderly fashion.
> Knock down any weeds and lay down weed killer in those spots.
>
> Need to make sure not to leave the HVAC on in there until we get equipment
> actually needing to be powered.
> Even then, we will want to set it no lower than 90 degrees.  Just got 15
> days worth of power bill (someone had left the AC on down to about 65
> degrees) and the bill was $100.  With no revenue producing customers yet, I
> don’t want recurring expenses.
> --
> AF mailing list
> AF@af.afmug.com
> http://af.afmug.com/mailman/listinfo/af_af.afmug.com
>


-- 
Lewis Bergman
325-439-0533 Cell
-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com


Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Mark Radabaugh
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) 
>  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  > 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 

Re: [AFMUG] 450i/450m DFS false detect problem solved in later firmware?

2020-07-13 Thread Forrest Christian (List Account)
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  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  *On Behalf Of *Forrest Christian
> (List Account)
> *Sent:* Sunday, July 12, 2020 7:56 PM
> *To:* AnimalFarm Microwave Users Group 
> *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  wrote:
>
> If they are not running 16.0.1 nuthing can help them from some weird
> issues with the DFS bands.
>
>