Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[Sean Heskett]

bwahahaha now this is a funny one.  I've been posting these same
discussions over on the cambium forums.  I've basically been talking to
myself over there because it seems no one hangs out there, not even the
cambium guys.  but for all my hard work posting replies to myself they
awarded me a "Badge"  I have never been so proud in my life!  I think i'm
gonna have it framed ;-)  see below lol...

Hi Sean Heskett,

You just earned a new badge!

*Reply 10*

Member has replied to 10 posts

View it on your profile

--

Thanks for being a Cambium Networks Community member.

*Your Cambium Networks Community Team*



On Wed, Jan 27, 2016 at 5:04 PM, Sean Heskett  wrote:

> also for what it's worth the APs that seem to have the most problems with
> the 14.1.1 software are the original APs from a few years ago with the FSK
> port on them.
>
> The newer APs and particularly the ones with the GLONASS GPS chip had the
> least if any problems.
>
>
>
> On Wed, Jan 27, 2016 at 4:35 PM, Sean Heskett  wrote:
>
>> so I gave up, our network and clients can't put up with all the memory
>> stack dumps, false DFS hits and registration failures that state "out of
>> range".
>>
>> I downgraded the APs to 13.2.1 and everything is stable once again.
>>
>> I look forward to a stable release of 14.1.1 for all the speed
>> improvements and the frame utilization stats etc. but I can't have our
>> network and clients suffer through buggy software anymore.
>>
>> 2 cents
>>
>> -Sean
>>
>>
>> On Tue, Jan 26, 2016 at 5:41 PM, George Skorup  wrote:
>>
>>> Yuck. 3.6 does the same kind of stuff. If a sector reboots, it can cause
>>> an LBT hit. It'll boot up and not quite be on the correct timing. Usually
>>> fine after a few seconds. Known issue though. DFS is different with the 30
>>> minute timeout. THAT really sucks.
>>>
>>> I have faith in the software guys though. They'll get the stack dumps
>>> and resets figured out. Because I'm sure they're really tired of hearing us
>>> bitch about it already. :)
>>>
>>> On 1/26/2016 6:27 PM, Sean Heskett wrote:
>>>
>>> yeah I saw the notes about the frame alignment.  I set them all to "on
>>> mode1" which didn't seem to help.
>>>
>>> after watching this for a couple more days it seems like what is
>>> happening is one AP on the tower will have a stack dump which causes other
>>> APs on the tower to register a DFS hit.
>>>
>>>
>>> then sometimes the DFS hit causes a stack dump in that AP.
>>>
>>>
>>> 14.1.1 has a lot of speed improvements but all the DFS hits that are now
>>> happening that didn't happen on 13.2.1 are causing issues.
>>>
>>>
>>> -Sean
>>>
>>> On Sun, Jan 24, 2016 at 5:02 PM, George Skorup 
>>> wrote:
>>>
 Did you read release notes regarding the frame alignment thing? If you
 didn't upgrade any 430 and 100 in the area, then you need to put the 450
 frame alignment into legacy mode. It shouldn't cause that many issues
 non-colocated, but since you're still seeing some DFS hits here and there,
 that could be the issue.

 And are you absolutely sure those APs could get sync over power before
 the upgrade? That seems really odd to just lose that ability... unless they
 changed something with power port pulse detection, which is entirely
 possible.

 On 1/24/2016 2:58 PM, Sean Heskett wrote:

 alright so after digging into this and making some adjustments I think
 i've got the DFS events settled down now.

 *1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the 5.4 band will
 delete "Alternate Frequency Carrier 1" and "Alternate Frequency
 Carrier 2".
 *Fix:* I had to log into each AP and manually add the 2 alternate
 channels back into the APs.  This way when we have a DFS event the AP will
 move to another channel.  Since the upgrade had deleted the 2 alternates
 the AP would shutdown for 30min.

 *2. Issue: *The tower that was having the most DFS issues has 11
 PMP450 APs and It's a commercial tower with a lot of FM stations etc.  All
 APs are connected to a CTM2 however after the upgrade half the APs were
 getting sync from the CTM2 over the power port and half didn't see any sync
 on the power port.
 *Fix:  *after reading other reports of the 450s having weird sync
 issues (causing other issues besides DFS events) I decided to force all 11
 APs to use the onboard GPS and I turned off the power port timing and
 timing port timing to achieve this.  So now all APs at this tower are
 receiving sync from the onboard GPS.

 *3.  Issue:* Somewhere along the line (13.x) cambium made it so that a
 450AP in the 5.4 band couldn't be set to more than 75% downlink.  We
 originally had them set for 85% downlink and they were timed with our 430
 APs.  Well 

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[George Skorup]

And +1 to the newer radios appearing to being more stable. Not all, but 
most.


On 1/27/2016 6:04 PM, Sean Heskett wrote:
also for what it's worth the APs that seem to have the most problems 
with the 14.1.1 software are the original APs from a few years ago 
with the FSK port on them.


The newer APs and particularly the ones with the GLONASS GPS chip had 
the least if any problems.




On Wed, Jan 27, 2016 at 4:35 PM, Sean Heskett > wrote:


so I gave up, our network and clients can't put up with all the
memory stack dumps, false DFS hits and registration failures that
state "out of range".

I downgraded the APs to 13.2.1 and everything is stable once again.

I look forward to a stable release of 14.1.1 for all the speed
improvements and the frame utilization stats etc. but I can't have
our network and clients suffer through buggy software anymore.

2 cents

-Sean


On Tue, Jan 26, 2016 at 5:41 PM, George Skorup > wrote:

Yuck. 3.6 does the same kind of stuff. If a sector reboots, it
can cause an LBT hit. It'll boot up and not quite be on the
correct timing. Usually fine after a few seconds. Known issue
though. DFS is different with the 30 minute timeout. THAT
really sucks.

I have faith in the software guys though. They'll get the
stack dumps and resets figured out. Because I'm sure they're
really tired of hearing us bitch about it already. :)

On 1/26/2016 6:27 PM, Sean Heskett wrote:

yeah I saw the notes about the frame alignment.  I set them
all to "on mode1" which didn't seem to help.

after watching this for a couple more days it seems like what
is happening is one AP on the tower will have a stack dump
which causes other APs on the tower to register a DFS hit.


then sometimes the DFS hit causes a stack dump in that AP.


14.1.1 has a lot of speed improvements but all the DFS hits
that are now happening that didn't happen on 13.2.1 are
causing issues.


-Sean

On Sun, Jan 24, 2016 at 5:02 PM, George Skorup
> wrote:

Did you read release notes regarding the frame alignment
thing? If you didn't upgrade any 430 and 100 in the area,
then you need to put the 450 frame alignment into legacy
mode. It shouldn't cause that many issues non-colocated,
but since you're still seeing some DFS hits here and
there, that could be the issue.

And are you absolutely sure those APs could get sync over
power before the upgrade? That seems really odd to just
lose that ability... unless they changed something with
power port pulse detection, which is entirely possible.

On 1/24/2016 2:58 PM, Sean Heskett wrote:

alright so after digging into this and making some
adjustments I think i've got the DFS events settled down
now.

*1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the
5.4 band will delete "Alternate Frequency Carrier 1" and
"Alternate Frequency Carrier 2".
*Fix:* I had to log into each AP and manually add the 2
alternate channels back into the APs.  This way when we
have a DFS event the AP will move to another channel. 
Since the upgrade had deleted the 2 alternates the AP

would shutdown for 30min.

*2. Issue: *The tower that was having the most DFS
issues has 11 PMP450 APs and It's a commercial tower
with a lot of FM stations etc. All APs are connected to
a CTM2 however after the upgrade half the APs were
getting sync from the CTM2 over the power port and half
didn't see any sync on the power port.
*Fix: *after reading other reports of the 450s having
weird sync issues (causing other issues besides DFS
events) I decided to force all 11 APs to use the onboard
GPS and I turned off the power port timing and timing
port timing to achieve this.  So now all APs at this
tower are receiving sync from the onboard GPS.

*3.  Issue:* Somewhere along the line (13.x) cambium
made it so that a 450AP in the 5.4 band couldn't be set
to more than 75% downlink.  We originally had them set
for 85% downlink and they were timed with our 430 APs. 
Well when cambium forced the change without any

notification suddenly our 450 APs were out of time with
our 430 APs. The area that this problem tower is located
we had removed all the 430 APs and moved them to smaller
towers at the edge 

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[Sean Heskett]

also for what it's worth the APs that seem to have the most problems with
the 14.1.1 software are the original APs from a few years ago with the FSK
port on them.

The newer APs and particularly the ones with the GLONASS GPS chip had the
least if any problems.



On Wed, Jan 27, 2016 at 4:35 PM, Sean Heskett  wrote:

> so I gave up, our network and clients can't put up with all the memory
> stack dumps, false DFS hits and registration failures that state "out of
> range".
>
> I downgraded the APs to 13.2.1 and everything is stable once again.
>
> I look forward to a stable release of 14.1.1 for all the speed
> improvements and the frame utilization stats etc. but I can't have our
> network and clients suffer through buggy software anymore.
>
> 2 cents
>
> -Sean
>
>
> On Tue, Jan 26, 2016 at 5:41 PM, George Skorup  wrote:
>
>> Yuck. 3.6 does the same kind of stuff. If a sector reboots, it can cause
>> an LBT hit. It'll boot up and not quite be on the correct timing. Usually
>> fine after a few seconds. Known issue though. DFS is different with the 30
>> minute timeout. THAT really sucks.
>>
>> I have faith in the software guys though. They'll get the stack dumps and
>> resets figured out. Because I'm sure they're really tired of hearing us
>> bitch about it already. :)
>>
>> On 1/26/2016 6:27 PM, Sean Heskett wrote:
>>
>> yeah I saw the notes about the frame alignment.  I set them all to "on
>> mode1" which didn't seem to help.
>>
>> after watching this for a couple more days it seems like what is
>> happening is one AP on the tower will have a stack dump which causes other
>> APs on the tower to register a DFS hit.
>>
>>
>> then sometimes the DFS hit causes a stack dump in that AP.
>>
>>
>> 14.1.1 has a lot of speed improvements but all the DFS hits that are now
>> happening that didn't happen on 13.2.1 are causing issues.
>>
>>
>> -Sean
>>
>> On Sun, Jan 24, 2016 at 5:02 PM, George Skorup  wrote:
>>
>>> Did you read release notes regarding the frame alignment thing? If you
>>> didn't upgrade any 430 and 100 in the area, then you need to put the 450
>>> frame alignment into legacy mode. It shouldn't cause that many issues
>>> non-colocated, but since you're still seeing some DFS hits here and there,
>>> that could be the issue.
>>>
>>> And are you absolutely sure those APs could get sync over power before
>>> the upgrade? That seems really odd to just lose that ability... unless they
>>> changed something with power port pulse detection, which is entirely
>>> possible.
>>>
>>> On 1/24/2016 2:58 PM, Sean Heskett wrote:
>>>
>>> alright so after digging into this and making some adjustments I think
>>> i've got the DFS events settled down now.
>>>
>>> *1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the 5.4 band will
>>> delete "Alternate Frequency Carrier 1" and "Alternate Frequency Carrier
>>> 2".
>>> *Fix:* I had to log into each AP and manually add the 2 alternate
>>> channels back into the APs.  This way when we have a DFS event the AP will
>>> move to another channel.  Since the upgrade had deleted the 2 alternates
>>> the AP would shutdown for 30min.
>>>
>>> *2. Issue: *The tower that was having the most DFS issues has 11 PMP450
>>> APs and It's a commercial tower with a lot of FM stations etc.  All APs are
>>> connected to a CTM2 however after the upgrade half the APs were getting
>>> sync from the CTM2 over the power port and half didn't see any sync on the
>>> power port.
>>> *Fix:  *after reading other reports of the 450s having weird sync
>>> issues (causing other issues besides DFS events) I decided to force all 11
>>> APs to use the onboard GPS and I turned off the power port timing and
>>> timing port timing to achieve this.  So now all APs at this tower are
>>> receiving sync from the onboard GPS.
>>>
>>> *3.  Issue:* Somewhere along the line (13.x) cambium made it so that a
>>> 450AP in the 5.4 band couldn't be set to more than 75% downlink.  We
>>> originally had them set for 85% downlink and they were timed with our 430
>>> APs.  Well when cambium forced the change without any notification suddenly
>>> our 450 APs were out of time with our 430 APs.  The area that this problem
>>> tower is located we had removed all the 430 APs and moved them to smaller
>>> towers at the edge of our network so I didn't think we'd have any timing
>>> issues since there were mountains blocking the signals.  However there was
>>> one tower with 430s still on it that was ~7 miles from this problem tower.
>>> *Fix:*  I changed the 430 timing to match the 450 timing at the
>>> problem tower.
>>>
>>> after running this weekend with the new settings I've only had 1 DFS
>>> event where as before these fixes the were a couple APs having DFS events
>>> 2-5 times a day.
>>>
>>> In conclusion it seems like 14.1.1 is WAY more sensitive in regards to
>>> timing sources.  Also 14.1.1 doesn't seem to reliably receive sync over
>>> power.  Again when were 

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[George Skorup]

Yup, I've seen the out of range thing quite a bit.

On 1/27/2016 5:35 PM, Sean Heskett wrote:
so I gave up, our network and clients can't put up with all the memory 
stack dumps, false DFS hits and registration failures that state "out 
of range".


I downgraded the APs to 13.2.1 and everything is stable once again.

I look forward to a stable release of 14.1.1 for all the speed 
improvements and the frame utilization stats etc. but I can't have our 
network and clients suffer through buggy software anymore.


2 cents

-Sean


On Tue, Jan 26, 2016 at 5:41 PM, George Skorup > wrote:


Yuck. 3.6 does the same kind of stuff. If a sector reboots, it can
cause an LBT hit. It'll boot up and not quite be on the correct
timing. Usually fine after a few seconds. Known issue though. DFS
is different with the 30 minute timeout. THAT really sucks.

I have faith in the software guys though. They'll get the stack
dumps and resets figured out. Because I'm sure they're really
tired of hearing us bitch about it already. :)

On 1/26/2016 6:27 PM, Sean Heskett wrote:

yeah I saw the notes about the frame alignment.  I set them all
to "on mode1" which didn't seem to help.

after watching this for a couple more days it seems like what is
happening is one AP on the tower will have a stack dump which
causes other APs on the tower to register a DFS hit.


then sometimes the DFS hit causes a stack dump in that AP.


14.1.1 has a lot of speed improvements but all the DFS hits that
are now happening that didn't happen on 13.2.1 are causing issues.


-Sean

On Sun, Jan 24, 2016 at 5:02 PM, George Skorup > wrote:

Did you read release notes regarding the frame alignment
thing? If you didn't upgrade any 430 and 100 in the area,
then you need to put the 450 frame alignment into legacy
mode. It shouldn't cause that many issues non-colocated, but
since you're still seeing some DFS hits here and there, that
could be the issue.

And are you absolutely sure those APs could get sync over
power before the upgrade? That seems really odd to just lose
that ability... unless they changed something with power port
pulse detection, which is entirely possible.

On 1/24/2016 2:58 PM, Sean Heskett wrote:

alright so after digging into this and making some
adjustments I think i've got the DFS events settled down now.

*1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the 5.4
band will delete "Alternate Frequency Carrier 1" and
"Alternate Frequency Carrier 2".
*Fix:* I had to log into each AP and manually add the 2
alternate channels back into the APs.  This way when we have
a DFS event the AP will move to another channel.  Since the
upgrade had deleted the 2 alternates the AP would shutdown
for 30min.

*2. Issue: *The tower that was having the most DFS issues
has 11 PMP450 APs and It's a commercial tower with a lot of
FM stations etc.  All APs are connected to a CTM2 however
after the upgrade half the APs were getting sync from the
CTM2 over the power port and half didn't see any sync on the
power port.
*Fix: *after reading other reports of the 450s having weird
sync issues (causing other issues besides DFS events) I
decided to force all 11 APs to use the onboard GPS and I
turned off the power port timing and timing port timing to
achieve this.  So now all APs at this tower are receiving
sync from the onboard GPS.

*3.  Issue:* Somewhere along the line (13.x) cambium made it
so that a 450AP in the 5.4 band couldn't be set to more than
75% downlink.  We originally had them set for 85% downlink
and they were timed with our 430 APs.  Well when cambium
forced the change without any notification suddenly our 450
APs were out of time with our 430 APs.  The area that this
problem tower is located we had removed all the 430 APs and
moved them to smaller towers at the edge of our network so I
didn't think we'd have any timing issues since there were
mountains blocking the signals. However there was one tower
with 430s still on it that was ~7 miles from this problem tower.
*Fix:*  I changed the 430 timing to match the 450 timing at
the problem tower.

after running this weekend with the new settings I've only
had 1 DFS event where as before these fixes the were a
couple APs having DFS events 2-5 times a day.

In conclusion it seems like 14.1.1 is WAY more sensitive in
regards to timing sources.  Also 14.1.1 doesn't seem to
reliably receive sync over power.  Again when were were on
   

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[George Skorup]

Yuck. 3.6 does the same kind of stuff. If a sector reboots, it can cause 
an LBT hit. It'll boot up and not quite be on the correct timing. 
Usually fine after a few seconds. Known issue though. DFS is different 
with the 30 minute timeout. THAT really sucks.


I have faith in the software guys though. They'll get the stack dumps 
and resets figured out. Because I'm sure they're really tired of hearing 
us bitch about it already. :)


On 1/26/2016 6:27 PM, Sean Heskett wrote:
yeah I saw the notes about the frame alignment.  I set them all to "on 
mode1" which didn't seem to help.


after watching this for a couple more days it seems like what is 
happening is one AP on the tower will have a stack dump which causes 
other APs on the tower to register a DFS hit.



then sometimes the DFS hit causes a stack dump in that AP.


14.1.1 has a lot of speed improvements but all the DFS hits that are 
now happening that didn't happen on 13.2.1 are causing issues.



-Sean

On Sun, Jan 24, 2016 at 5:02 PM, George Skorup > wrote:


Did you read release notes regarding the frame alignment thing? If
you didn't upgrade any 430 and 100 in the area, then you need to
put the 450 frame alignment into legacy mode. It shouldn't cause
that many issues non-colocated, but since you're still seeing some
DFS hits here and there, that could be the issue.

And are you absolutely sure those APs could get sync over power
before the upgrade? That seems really odd to just lose that
ability... unless they changed something with power port pulse
detection, which is entirely possible.

On 1/24/2016 2:58 PM, Sean Heskett wrote:

alright so after digging into this and making some adjustments I
think i've got the DFS events settled down now.

*1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the 5.4 band
will delete "Alternate Frequency Carrier 1" and "Alternate
Frequency Carrier 2".
*Fix:* I had to log into each AP and manually add the 2 alternate
channels back into the APs.  This way when we have a DFS event
the AP will move to another channel.  Since the upgrade had
deleted the 2 alternates the AP would shutdown for 30min.

*2. Issue: *The tower that was having the most DFS issues has 11
PMP450 APs and It's a commercial tower with a lot of FM stations
etc. All APs are connected to a CTM2 however after the upgrade
half the APs were getting sync from the CTM2 over the power port
and half didn't see any sync on the power port.
*Fix: *after reading other reports of the 450s having weird sync
issues (causing other issues besides DFS events) I decided to
force all 11 APs to use the onboard GPS and I turned off the
power port timing and timing port timing to achieve this.  So now
all APs at this tower are receiving sync from the onboard GPS.

*3.  Issue:* Somewhere along the line (13.x) cambium made it so
that a 450AP in the 5.4 band couldn't be set to more than 75%
downlink. We originally had them set for 85% downlink and they
were timed with our 430 APs.  Well when cambium forced the change
without any notification suddenly our 450 APs were out of time
with our 430 APs.  The area that this problem tower is located we
had removed all the 430 APs and moved them to smaller towers at
the edge of our network so I didn't think we'd have any timing
issues since there were mountains blocking the signals. However
there was one tower with 430s still on it that was ~7 miles from
this problem tower.
*Fix:*  I changed the 430 timing to match the 450 timing at the
problem tower.

after running this weekend with the new settings I've only had 1
DFS event where as before these fixes the were a couple APs
having DFS events 2-5 times a day.

In conclusion it seems like 14.1.1 is WAY more sensitive in
regards to timing sources.  Also 14.1.1 doesn't seem to reliably
receive sync over power.  Again when were were on 13.2.1 we
didn't have any of these issues.  14.1.1 introduced some timing
and DFS issues but they are somewhat manageable (i really hate
turning off a sync source because it'd be nice to have it as a
backup).  It seems like if a nearby AP is out of sync that will
trigger a DFS event.

2 cents.  I'll report again in a few days to see if these fixes
have eliminated the DFS events.

-Sean



On Wed, Jan 20, 2016 at 5:41 PM, Sean Heskett > wrote:

I will be opening a ticket with cambium but I wanted to let
everyone know this issues we just came across.

I updated all our 450 APs to 14.1.1 yesterday.  On our 5Ghz
450s we use the 5.4 band.  On all these APs the "Alternate
Frequency Carrier 1" and "Alternate Frequency Carrier 2" were
reset to "none".  when I go and set them back to what they
   

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[Sean Heskett]

alright so after digging into this and making some adjustments I think i've
got the DFS events settled down now.

*1. Issue:*  The 14.1.1 upgrade on PMP450 APs using the 5.4 band will
delete "Alternate Frequency Carrier 1" and "Alternate Frequency Carrier 2".
*Fix:* I had to log into each AP and manually add the 2 alternate
channels back into the APs.  This way when we have a DFS event the AP will
move to another channel.  Since the upgrade had deleted the 2 alternates
the AP would shutdown for 30min.

*2. Issue: *The tower that was having the most DFS issues has 11 PMP450 APs
and It's a commercial tower with a lot of FM stations etc.  All APs are
connected to a CTM2 however after the upgrade half the APs were getting
sync from the CTM2 over the power port and half didn't see any sync on the
power port.
*Fix:  *after reading other reports of the 450s having weird sync
issues (causing other issues besides DFS events) I decided to force all 11
APs to use the onboard GPS and I turned off the power port timing and
timing port timing to achieve this.  So now all APs at this tower are
receiving sync from the onboard GPS.

*3.  Issue:* Somewhere along the line (13.x) cambium made it so that a
450AP in the 5.4 band couldn't be set to more than 75% downlink.  We
originally had them set for 85% downlink and they were timed with our 430
APs.  Well when cambium forced the change without any notification suddenly
our 450 APs were out of time with our 430 APs.  The area that this problem
tower is located we had removed all the 430 APs and moved them to smaller
towers at the edge of our network so I didn't think we'd have any timing
issues since there were mountains blocking the signals.  However there was
one tower with 430s still on it that was ~7 miles from this problem tower.
*Fix:*  I changed the 430 timing to match the 450 timing at the problem
tower.

after running this weekend with the new settings I've only had 1 DFS event
where as before these fixes the were a couple APs having DFS events 2-5
times a day.

In conclusion it seems like 14.1.1 is WAY more sensitive in regards to
timing sources.  Also 14.1.1 doesn't seem to reliably receive sync over
power.  Again when were were on 13.2.1 we didn't have any of these issues.
 14.1.1 introduced some timing and DFS issues but they are somewhat
manageable (i really hate turning off a sync source because it'd be nice to
have it as a backup).  It seems like if a nearby AP is out of sync that
will trigger a DFS event.

2 cents.  I'll report again in a few days to see if these fixes have
eliminated the DFS events.

-Sean



On Wed, Jan 20, 2016 at 5:41 PM, Sean Heskett  wrote:

> I will be opening a ticket with cambium but I wanted to let everyone know
> this issues we just came across.
>
> I updated all our 450 APs to 14.1.1 yesterday.  On our 5Ghz 450s we use
> the 5.4 band.  On all these APs the "Alternate Frequency Carrier 1" and
> "Alternate Frequency Carrier 2" were reset to "none".  when I go and set
> them back to what they should be, save and reboot they still come back as
> "none".
>
> Because of this if we experience a DFS event we have no other frequency to
> hop to.
>
> Additionally we have a couple APs that after the upgrade are now seeing
> DFS events when previously they experienced no events...ever.  We live in
> the middle of the rocky mtns. so there really shouldn't be any events
> because of all the granite clouds in the way ;-)
>
> anyway, DFS seems to be broken on 14.1.1 and I wanted to let everyone know
> before they apply the upgrade incase you need DFS to work properly.
>
> -Sean
>
>

Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

[Ken Hohhof]

That’s very impressive progress, kudos and thanks for the info.

From: Sean Heskett 
Sent: Sunday, January 24, 2016 2:58 PM
To: af@afmug.com ; memb...@wispa.org 
Subject: Re: [AFMUG] Canopy 14.1.1 DFS problems :-/

alright so after digging into this and making some adjustments I think i've got 
the DFS events settled down now. 

1. Issue:  The 14.1.1 upgrade on PMP450 APs using the 5.4 band will delete 
"Alternate Frequency Carrier 1" and "Alternate Frequency Carrier 2".
Fix: I had to log into each AP and manually add the 2 alternate channels 
back into the APs.  This way when we have a DFS event the AP will move to 
another channel.  Since the upgrade had deleted the 2 alternates the AP would 
shutdown for 30min.


2. Issue: The tower that was having the most DFS issues has 11 PMP450 APs and 
It's a commercial tower with a lot of FM stations etc.  All APs are connected 
to a CTM2 however after the upgrade half the APs were getting sync from the 
CTM2 over the power port and half didn't see any sync on the power port.  
Fix:  after reading other reports of the 450s having weird sync issues 
(causing other issues besides DFS events) I decided to force all 11 APs to use 
the onboard GPS and I turned off the power port timing and timing port timing 
to achieve this.  So now all APs at this tower are receiving sync from the 
onboard GPS.

3.  Issue: Somewhere along the line (13.x) cambium made it so that a 450AP in 
the 5.4 band couldn't be set to more than 75% downlink.  We originally had them 
set for 85% downlink and they were timed with our 430 APs.  Well when cambium 
forced the change without any notification suddenly our 450 APs were out of 
time with our 430 APs.  The area that this problem tower is located we had 
removed all the 430 APs and moved them to smaller towers at the edge of our 
network so I didn't think we'd have any timing issues since there were 
mountains blocking the signals.  However there was one tower with 430s still on 
it that was ~7 miles from this problem tower.
Fix:  I changed the 430 timing to match the 450 timing at the problem tower.

after running this weekend with the new settings I've only had 1 DFS event 
where as before these fixes the were a couple APs having DFS events 2-5 times a 
day.

In conclusion it seems like 14.1.1 is WAY more sensitive in regards to timing 
sources.  Also 14.1.1 doesn't seem to reliably receive sync over power.  Again 
when were were on 13.2.1 we didn't have any of these issues.  14.1.1 introduced 
some timing and DFS issues but they are somewhat manageable (i really hate 
turning off a sync source because it'd be nice to have it as a backup).  It 
seems like if a nearby AP is out of sync that will trigger a DFS event.

2 cents.  I'll report again in a few days to see if these fixes have eliminated 
the DFS events.

-Sean



On Wed, Jan 20, 2016 at 5:41 PM, Sean Heskett <af...@zirkel.us> wrote:

  I will be opening a ticket with cambium but I wanted to let everyone know 
this issues we just came across. 

  I updated all our 450 APs to 14.1.1 yesterday.  On our 5Ghz 450s we use the 
5.4 band.  On all these APs the "Alternate Frequency Carrier 1" and "Alternate 
Frequency Carrier 2" were reset to "none".  when I go and set them back to what 
they should be, save and reboot they still come back as "none".

  Because of this if we experience a DFS event we have no other frequency to 
hop to.

  Additionally we have a couple APs that after the upgrade are now seeing DFS 
events when previously they experienced no events...ever.  We live in the 
middle of the rocky mtns. so there really shouldn't be any events because of 
all the granite clouds in the way ;-)

  anyway, DFS seems to be broken on 14.1.1 and I wanted to let everyone know 
before they apply the upgrade incase you need DFS to work properly.

  -Sean

[AFMUG] Canopy 14.1.1 DFS problems :-/

[Sean Heskett]

I will be opening a ticket with cambium but I wanted to let everyone know
this issues we just came across.

I updated all our 450 APs to 14.1.1 yesterday.  On our 5Ghz 450s we use the
5.4 band.  On all these APs the "Alternate Frequency Carrier 1" and
"Alternate Frequency Carrier 2" were reset to "none".  when I go and set
them back to what they should be, save and reboot they still come back as
"none".

Because of this if we experience a DFS event we have no other frequency to
hop to.

Additionally we have a couple APs that after the upgrade are now seeing DFS
events when previously they experienced no events...ever.  We live in the
middle of the rocky mtns. so there really shouldn't be any events because
of all the granite clouds in the way ;-)

anyway, DFS seems to be broken on 14.1.1 and I wanted to let everyone know
before they apply the upgrade incase you need DFS to work properly.

-Sean

Re: [AFMUG] Canopy 14.1.1

[Darren Shea]

Aaron,
That's great news - thanks for the quick response!

  -- Darren

-Original Message-
From: Aaron Schneider [mailto:aaron.schnei...@cambiumnetworks.com] 
Sent: Wednesday, December 02, 2015 9:38 AM
To: af@afmug.com; Darren Shea
Subject: RE: [AFMUG] Canopy 14.1.1

Well, I must correct myself!  While there is an integrated patch antenna, its 
gain is part of the 25dBi total gain, not in addition to, so you are correct, 
we are off by 9-10 dB and are too low.   This explains the questions raised at 
Wispapalooza and what you are seeing here.  The good news is that this is 
fixable via SW and we will obviously get this fixed ASAP.  I'll let you know 
when we have an Open Beta load for you to use, it should be within a day or so 
here, and we will expedite a formal released load fixing this.  

Regards,
-Aaron

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Aaron Schneider
Sent: Tuesday, December 01, 2015 5:19 PM
To: Darren Shea; af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1

Darren -

We'll take a look but the external gain for 450D is locked because that is the 
property of the HW with the attached dish and radome.  This is not changeable 
intentionally.  

The internal HW of the 450d is actually an integrated 450SM in a new housing, 
so there actually is some internal gain via the 9dBi patch antenna, so that 
would account for the  difference.  So TxPower + internal patch gain + external 
dish gain <= EIRP would mean -4 is our max TxPower for 5.4 FCC to stay <= 30 dB 
EIRP.
  
However, we will take a look - there was some feedback at Wispapalooza that 
some customers were having issues installing these in 5.4G band, but the tx 
power should be correct.

Regards,
-Aaron


-Original Message-
From: Darren Shea [mailto:darr...@ecpi.com] 
Sent: Tuesday, December 01, 2015 3:58 PM
To: af@afmug.com
Cc: Matt Mangriotis; Aaron Schneider
Subject: RE: [AFMUG] Canopy 14.1.1

Aaron,
I had a question about a change Cambium implemented on  the 450D radios, 
although it's not new to 14.1.1 (I think it started in 13.4):  the Power 
Control section on the Configuration -> Radio, External Gain setting is no 
longer adjustable, and is locked in at 25dB. OK, but the radio seems to be 
thinking it's got some sort of additional gain, because it won't transmit 
higher than -5dB (reported in Link Status). Shouldn't the EIRP in the DFS band 
be 30dB, so it could transmit as high as 5 dB? This seems to be causing a major 
connectivity issue in the 5.4 band, but not in the 5.7 band, where transmit 
power is reported as anywhere from 16 to 22dB on the same SM to the same test 
AP.

Why the disparity? Is there any hope for using 5.4 GHz frequencies on a 450D SM 
to a tower you could not hit with a football?

Re: [AFMUG] Canopy 14.1.1

[Josh Luthman]

Way to go Darren for catching the mistake!!!


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

On Wed, Dec 2, 2015 at 10:58 AM, Darren Shea <darr...@ecpi.com> wrote:

> Aaron,
> That's great news - thanks for the quick response!
>
>   -- Darren
>
> -Original Message-
> From: Aaron Schneider [mailto:aaron.schnei...@cambiumnetworks.com]
> Sent: Wednesday, December 02, 2015 9:38 AM
> To: af@afmug.com; Darren Shea
> Subject: RE: [AFMUG] Canopy 14.1.1
>
> Well, I must correct myself!  While there is an integrated patch antenna,
> its gain is part of the 25dBi total gain, not in addition to, so you are
> correct, we are off by 9-10 dB and are too low.   This explains the
> questions raised at Wispapalooza and what you are seeing here.  The good
> news is that this is fixable via SW and we will obviously get this fixed
> ASAP.  I'll let you know when we have an Open Beta load for you to use, it
> should be within a day or so here, and we will expedite a formal released
> load fixing this.
>
> Regards,
> -Aaron
>
> -Original Message-
> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Aaron Schneider
> Sent: Tuesday, December 01, 2015 5:19 PM
> To: Darren Shea; af@afmug.com
> Subject: Re: [AFMUG] Canopy 14.1.1
>
> Darren -
>
> We'll take a look but the external gain for 450D is locked because that is
> the property of the HW with the attached dish and radome.  This is not
> changeable intentionally.
>
> The internal HW of the 450d is actually an integrated 450SM in a new
> housing, so there actually is some internal gain via the 9dBi patch
> antenna, so that would account for the  difference.  So TxPower + internal
> patch gain + external dish gain <= EIRP would mean -4 is our max TxPower
> for 5.4 FCC to stay <= 30 dB EIRP.
>
> However, we will take a look - there was some feedback at Wispapalooza
> that some customers were having issues installing these in 5.4G band, but
> the tx power should be correct.
>
> Regards,
> -Aaron
>
>
> -Original Message-
> From: Darren Shea [mailto:darr...@ecpi.com]
> Sent: Tuesday, December 01, 2015 3:58 PM
> To: af@afmug.com
> Cc: Matt Mangriotis; Aaron Schneider
> Subject: RE: [AFMUG] Canopy 14.1.1
>
> Aaron,
> I had a question about a change Cambium implemented on  the 450D
> radios, although it's not new to 14.1.1 (I think it started in 13.4):  the
> Power Control section on the Configuration -> Radio, External Gain setting
> is no longer adjustable, and is locked in at 25dB. OK, but the radio seems
> to be thinking it's got some sort of additional gain, because it won't
> transmit higher than -5dB (reported in Link Status). Shouldn't the EIRP in
> the DFS band be 30dB, so it could transmit as high as 5 dB? This seems to
> be causing a major connectivity issue in the 5.4 band, but not in the 5.7
> band, where transmit power is reported as anywhere from 16 to 22dB on the
> same SM to the same test AP.
>
> Why the disparity? Is there any hope for using 5.4 GHz frequencies on a
> 450D SM to a tower you could not hit with a football?
>
>
>
>

Re: [AFMUG] Canopy 14.1.1

[George Skorup]

Good thing I haven't updated anything yet. :) Can you guys also add 
3652.5 and 3697.5 back to the 3.6 default frequencies list? Also, the 
upstream direction in the filter config used to be on by default and is 
not now on 14.1.1. Would be nice if it was restored because I'm sure the 
guys won't catch that's it's off now.


On 12/2/2015 9:38 AM, Aaron Schneider wrote:

Well, I must correct myself!  While there is an integrated patch antenna, its 
gain is part of the 25dBi total gain, not in addition to, so you are correct, 
we are off by 9-10 dB and are too low.   This explains the questions raised at 
Wispapalooza and what you are seeing here.  The good news is that this is 
fixable via SW and we will obviously get this fixed ASAP.  I'll let you know 
when we have an Open Beta load for you to use, it should be within a day or so 
here, and we will expedite a formal released load fixing this.

Regards,
-Aaron

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Aaron Schneider
Sent: Tuesday, December 01, 2015 5:19 PM
To: Darren Shea; af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1

Darren -

We'll take a look but the external gain for 450D is locked because that is the 
property of the HW with the attached dish and radome.  This is not changeable 
intentionally.

The internal HW of the 450d is actually an integrated 450SM in a new housing, so 
there actually is some internal gain via the 9dBi patch antenna, so that would 
account for the  difference.  So TxPower + internal patch gain + external dish gain 
<= EIRP would mean -4 is our max TxPower for 5.4 FCC to stay <= 30 dB EIRP.
   
However, we will take a look - there was some feedback at Wispapalooza that some customers were having issues installing these in 5.4G band, but the tx power should be correct.


Regards,
-Aaron


-Original Message-
From: Darren Shea [mailto:darr...@ecpi.com]
Sent: Tuesday, December 01, 2015 3:58 PM
To: af@afmug.com
Cc: Matt Mangriotis; Aaron Schneider
Subject: RE: [AFMUG] Canopy 14.1.1

Aaron,
 I had a question about a change Cambium implemented on  the 450D radios, 
although it's not new to 14.1.1 (I think it started in 13.4):  the Power Control 
section on the Configuration -> Radio, External Gain setting is no longer 
adjustable, and is locked in at 25dB. OK, but the radio seems to be thinking it's 
got some sort of additional gain, because it won't transmit higher than -5dB 
(reported in Link Status). Shouldn't the EIRP in the DFS band be 30dB, so it could 
transmit as high as 5 dB? This seems to be causing a major connectivity issue in 
the 5.4 band, but not in the 5.7 band, where transmit power is reported as 
anywhere from 16 to 22dB on the same SM to the same test AP.

Why the disparity? Is there any hope for using 5.4 GHz frequencies on a 450D SM 
to a tower you could not hit with a football?

Re: [AFMUG] Canopy 14.1.1

[Darren Shea]

Aaron,
I had a question about a change Cambium implemented on  the 450D radios, 
although it's not new to 14.1.1 (I think it started in 13.4):  the Power 
Control section on the Configuration -> Radio, External Gain setting is no 
longer adjustable, and is locked in at 25dB. OK, but the radio seems to be 
thinking it's got some sort of additional gain, because it won't transmit 
higher than -5dB (reported in Link Status). Shouldn't the EIRP in the DFS band 
be 30dB, so it could transmit as high as 5 dB? This seems to be causing a major 
connectivity issue in the 5.4 band, but not in the 5.7 band, where transmit 
power is reported as anywhere from 16 to 22dB on the same SM to the same test 
AP.

Why the disparity? Is there any hope for using 5.4 GHz frequencies on a 450D SM 
to a tower you could not hit with a football?

Re: [AFMUG] Canopy 14.1.1

[Aaron Schneider]

Darren -

We'll take a look but the external gain for 450D is locked because that is the 
property of the HW with the attached dish and radome.  This is not changeable 
intentionally.  

The internal HW of the 450d is actually an integrated 450SM in a new housing, 
so there actually is some internal gain via the 9dBi patch antenna, so that 
would account for the  difference.  So TxPower + internal patch gain + external 
dish gain <= EIRP would mean -4 is our max TxPower for 5.4 FCC to stay <= 30 dB 
EIRP.
  
However, we will take a look - there was some feedback at Wispapalooza that 
some customers were having issues installing these in 5.4G band, but the tx 
power should be correct.

Regards,
-Aaron


-Original Message-
From: Darren Shea [mailto:darr...@ecpi.com] 
Sent: Tuesday, December 01, 2015 3:58 PM
To: af@afmug.com
Cc: Matt Mangriotis; Aaron Schneider
Subject: RE: [AFMUG] Canopy 14.1.1

Aaron,
I had a question about a change Cambium implemented on  the 450D radios, 
although it's not new to 14.1.1 (I think it started in 13.4):  the Power 
Control section on the Configuration -> Radio, External Gain setting is no 
longer adjustable, and is locked in at 25dB. OK, but the radio seems to be 
thinking it's got some sort of additional gain, because it won't transmit 
higher than -5dB (reported in Link Status). Shouldn't the EIRP in the DFS band 
be 30dB, so it could transmit as high as 5 dB? This seems to be causing a major 
connectivity issue in the 5.4 band, but not in the 5.7 band, where transmit 
power is reported as anywhere from 16 to 22dB on the same SM to the same test 
AP.

Why the disparity? Is there any hope for using 5.4 GHz frequencies on a 450D SM 
to a tower you could not hit with a football?

Re: [AFMUG] Canopy 14.1.1

[George Skorup]

But if the locked external gain is set to 25dB, that's the whole system 
gain, not the addition of the "external" gain (over the bare patch) like 
a reflector. For instance, you set external gain to +14 when using a 
standard SM on a reflector and get the full legal +30dBm/20MHz or 
+27dBm/10MHz for DFS channels. That's the way I've always understood the 
external gain setting. So -5dBm auto Tx power probably means it thinks 
it has 9dB + 25dB = 34dB total system gain which would be very incorrect.


On 12/1/2015 5:18 PM, Aaron Schneider wrote:

Darren -

We'll take a look but the external gain for 450D is locked because that is the 
property of the HW with the attached dish and radome.  This is not changeable 
intentionally.

The internal HW of the 450d is actually an integrated 450SM in a new housing, so 
there actually is some internal gain via the 9dBi patch antenna, so that would 
account for the  difference.  So TxPower + internal patch gain + external dish gain 
<= EIRP would mean -4 is our max TxPower for 5.4 FCC to stay <= 30 dB EIRP.
   
However, we will take a look - there was some feedback at Wispapalooza that some customers were having issues installing these in 5.4G band, but the tx power should be correct.


Regards,
-Aaron


-Original Message-
From: Darren Shea [mailto:darr...@ecpi.com]
Sent: Tuesday, December 01, 2015 3:58 PM
To: af@afmug.com
Cc: Matt Mangriotis; Aaron Schneider
Subject: RE: [AFMUG] Canopy 14.1.1

Aaron,
 I had a question about a change Cambium implemented on  the 450D radios, 
although it's not new to 14.1.1 (I think it started in 13.4):  the Power Control 
section on the Configuration -> Radio, External Gain setting is no longer 
adjustable, and is locked in at 25dB. OK, but the radio seems to be thinking it's 
got some sort of additional gain, because it won't transmit higher than -5dB 
(reported in Link Status). Shouldn't the EIRP in the DFS band be 30dB, so it could 
transmit as high as 5 dB? This seems to be causing a major connectivity issue in 
the 5.4 band, but not in the 5.7 band, where transmit power is reported as 
anywhere from 16 to 22dB on the same SM to the same test AP.

Why the disparity? Is there any hope for using 5.4 GHz frequencies on a 450D SM 
to a tower you could not hit with a football?

Re: [AFMUG] Canopy 14.1.1

[George Skorup]

For anyone that may be interested, Cambium put up 13.2.1.3 (for Lite 
APs) in the PMP450 Archive section.


On 11/25/2015 10:06 PM, Aaron Schneider wrote:

I can help if that is necessary.  I’ll forward this on internally.




On 11/25/15, 6:02 PM, "Af on behalf of George Skorup"  wrote:


I see it made it to the support site today. How about putting up
13.2.1.3 for us with Lite APs that may want to go back?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Matt]

Any chance a PTP450i or PTP450 could talk to a PTP430?  Would make some
pending upgrades SO much easier.


On Mon, Nov 30, 2015 at 11:49 AM, Aaron Schneider <
aaron.schnei...@cambiumnetworks.com> wrote:

> Yes, just be aware that for 430 to talk to 450i AP in its native mode, the
> 430's will need to be the latest 13.4.1 Open Beta.  Otherwise, you'll have
> to enable the "legacy mode" on the 450i AP to let the older SW register.
> Enabling this mode limits the radio HW Queue depths to be compatible with
> the older SW.
>
>
>
> The SMs need to be upgraded to be able to detect these new depths and
> adapt automatically during registration.  For 430, 13.4.1 was the first
> load which supports this, and for 450, 13.3 was the first load which
> supports this (it originally came with 5ms Frame support, which was/is a
> 450/450i only feature).
>
>
>
> You can find this option on the 450i AP's Radio Configuration page:
>
>
>
>
>
> This is only there for you to use for migration of SW releases – it is not
> meant to be on indefinitely once all of your SMs are on acceptable releases
> (which is now 14.1.1 for 450i/450 sectors, including 450/430 SMs), as
> having it on will impact the performance capability of the 450i AP.
>
>
>
> Regards,
>
> -Aaron
>
>
>
>
>
> -Original Message-
> From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sriram Chaturvedi
> Sent: Saturday, November 28, 2015 1:06 PM
> To: af@afmug.com
> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>
>
>
> Yes you can, Mark.
>
>
>
> 
>
> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <
> m...@amplex.net>
>
> Sent: Saturday, November 28, 2015 12:35 PM
>
> To: af@afmug.com
>
> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>
>
>
> We have a number of towers to convert from 4 450’s with 90 degree sectors
> to 6 AP’s with 60 degree sectors.   Most of these are already at 80-90% 450
> SM’s.   I was asking if I can go directly to 450i AP’s without having to
> finish collecting the 430’s.
>
>
>
> Mark
>
>
>
> > On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi <
> sriram.chaturv...@cambiumnetworks.com> wrote:
>
> >
>
> > Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade”
> project where I assumed he was eventually going to upgrade his 430 SMs to
> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my
> responses aren’t loaded when I post here.
>
> >
>
> >
>
> >> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
>
> >>
>
> >> "right away" sounds ominous
>
> >>
>
> >>
>
> >> -Original Message- From: Sriram Chaturvedi
>
> >> Sent: Saturday, November 28, 2015 8:00 AM
>
> >> To: af@afmug.com
>
> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>
> >>
>
> >> 450i AP will interop with 430 SMs. You don't need to swap the SMs out
> right away.
>
> >>
>
> >> Thanks,
>
> >> Sriram
>
> >>
>
> >> 
>
> >> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <
> m...@amplex.net>
>
> >> Sent: Saturday, November 28, 2015 8:24 AM
>
> >> To: af@afmug.com
>
> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>
> >>
>
> >> How about 450i AP to 430 SM? I would like to start deploying 450i
> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430
> SM�s swapped first?
>
> >>
>
> >> Mark
>
> >>
>
> >>
>
> >>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider <
> aaron.schnei...@cambiumnetworks.com> wrote:
>
> >>>
>
> >>> It should work, but at the moment I can�t recall if/when we tried
> this with PTP mode.  I�ll let you know.
>
> >>>
>
> >>> 450i - 450 isn�t really an �interop� situation like 430 - 450
> was.  430 - 450 was quite a bit different, needing SISO to talk to MIMO
> with the way we did MIMO at first (MIMO-B using both channels for data).
> 450i - 450 is much more similar, and we have been using that combination
> internally for a long time.  It wasn�t part of the initial release of
> 450i due to needing to focus on the HW release itself.
>
> >>>
>
> >>> I�ll be in touch on the PTP question.  It is important to allow you
> to upgrade a PTP link one end at a time.
>
> >>>
>
> >>> Regards,
>
> >>> -Aaron
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
> >>> <af-boun...@afmug.com
> on behalf of geo...@cbcast.com> wrote:
>
> >>>
>
> >>>> I thought interop was only for PMP?
>
> >>>>
>
> >>>> On 11/26/2015 11:38 PM, Matt wrote:
>
> >>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>
> >>>>
>
> >>
>
> >
>
> >
>
>
>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[George Skorup]

When are we looking at 13.4.1 official? It would be nice to bring up all 
of the FSK to 13.4.1 official and 450 to 14.1.1 at the same time.


On 11/30/2015 11:49 AM, Aaron Schneider wrote:


Yes, just be aware that for 430 to talk to 450i AP in its native mode, 
the 430's will need to be the latest 13.4.1 Open Beta.  Otherwise, 
you'll have to enable the "legacy mode" on the 450i AP to let the 
older SW register. Enabling this mode limits the radio HW Queue depths 
to be compatible with the older SW.


The SMs need to be upgraded to be able to detect these new depths and 
adapt automatically during registration.  For 430, 13.4.1 was the 
first load which supports this, and for 450, 13.3 was the first load 
which supports this (it originally came with 5ms Frame support, which 
was/is a 450/450i only feature).


You can find this option on the 450i AP's Radio Configuration page:

This is only there for you to use for migration of SW releases � it is 
not meant to be on indefinitely once all of your SMs are on acceptable 
releases (which is now 14.1.1 for 450i/450 sectors, including 450/430 
SMs), as having it on will impact the performance capability of the 
450i AP.


Regards,

-Aaron

-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sriram Chaturvedi
Sent: Saturday, November 28, 2015 1:06 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Yes you can, Mark.



From: Af <af-boun...@afmug.com <mailto:af-boun...@afmug.com>> on 
behalf of Mark Radabaugh <m...@amplex.net <mailto:m...@amplex.net>>


Sent: Saturday, November 28, 2015 12:35 PM

To: af@afmug.com <mailto:af@afmug.com>

Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

We have a number of towers to convert from 4 450�s with 90 degree 
sectors to 6 AP�s with 60 degree sectors.   Most of these are already 
at 80-90% 450 SM�s.   I was asking if I can go directly to 450i AP�s 
without having to finish collecting the 430�s.


Mark

> On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
<sriram.chaturv...@cambiumnetworks.com 
<mailto:sriram.chaturv...@cambiumnetworks.com>> wrote:


>

> Hi Chuck, I was directly responding to Mark�s question on 430 
�upgrade� project where I assumed he was eventually going to upgrade 
his 430 SMs to 450/450i. Perhaps it was an incorrect assumption. 
Believe it or not, my responses aren�t loaded when I post here.


>

>

>> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com 
<mailto:ch...@wbmfg.com>> wrote:


>>

>> "right away" sounds ominous

>>

>>

>> -Original Message- From: Sriram Chaturvedi

>> Sent: Saturday, November 28, 2015 8:00 AM

>> To: af@afmug.com <mailto:af@afmug.com>

>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

>>

>> 450i AP will interop with 430 SMs. You don't need to swap the SMs 
out right away.


>>

>> Thanks,

>> Sriram

>>

>> 

>> From: Af <af-boun...@afmug.com <mailto:af-boun...@afmug.com>> on 
behalf of Mark Radabaugh <m...@amplex.net <mailto:m...@amplex.net>>


>> Sent: Saturday, November 28, 2015 8:24 AM

>> To: af@afmug.com <mailto:af@afmug.com>

>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

>>

>> How about 450i AP to 430 SM? I would like to start deploying 
450i instead of 450 for 430 upgrade projects.  Do I have to get all of 
the 430 SM�s swapped first?


>>

>> Mark

>>

>>

>>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com 
<mailto:aaron.schnei...@cambiumnetworks.com>> wrote:


>>>

>>> It should work, but at the moment I can�t recall if/when we 
tried this with PTP mode. I�ll let you know.


>>>

>>> 450i - 450 isn�t really an �interop� situation like 430 - 
450 was.  430 - 450 was quite a bit different, needing SISO to talk to 
MIMO with the way we did MIMO at first (MIMO-B using both channels for 
data).  450i - 450 is much more similar, and we have been using that 
combination internally for a long time.  It wasn�t part of the 
initial release of 450i due to needing to focus on the HW release itself.


>>>

>>> I�ll be in touch on the PTP question.  It is important to allow 
you to upgrade a PTP link one end at a time.


>>>

>>> Regards,

>>> -Aaron

>>>

>>>

>>>

>>>

>>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com 
<mailto:af-boun...@afmug.com%20on%20behalf%20of%20geo...@cbcast.com>> 
wrote:


>>>

>>>> I thought interop was only for PMP?

>>>>

>>>> On 11/26/2015 11:38 PM, Matt wrote:

>>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?

>>>>

>>

>

>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Aaron Schneider]

Yes, just be aware that for 430 to talk to 450i AP in its native mode, the 
430's will need to be the latest 13.4.1 Open Beta.  Otherwise, you'll have to 
enable the "legacy mode" on the 450i AP to let the older SW register.  Enabling 
this mode limits the radio HW Queue depths to be compatible with the older SW.



The SMs need to be upgraded to be able to detect these new depths and adapt 
automatically during registration.  For 430, 13.4.1 was the first load which 
supports this, and for 450, 13.3 was the first load which supports this (it 
originally came with 5ms Frame support, which was/is a 450/450i only feature).



You can find this option on the 450i AP's Radio Configuration page:



[cid:image002.jpg@01D12B65.35FCDB70]



This is only there for you to use for migration of SW releases - it is not 
meant to be on indefinitely once all of your SMs are on acceptable releases 
(which is now 14.1.1 for 450i/450 sectors, including 450/430 SMs), as having it 
on will impact the performance capability of the 450i AP.



Regards,

-Aaron





-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sriram Chaturvedi
Sent: Saturday, November 28, 2015 1:06 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP



Yes you can, Mark.





From: Af <af-boun...@afmug.com<mailto:af-boun...@afmug.com>> on behalf of Mark 
Radabaugh <m...@amplex.net<mailto:m...@amplex.net>>

Sent: Saturday, November 28, 2015 12:35 PM

To: af@afmug.com<mailto:af@afmug.com>

Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP



We have a number of towers to convert from 4 450's with 90 degree sectors to 6 
AP's with 60 degree sectors.   Most of these are already at 80-90% 450 SM's.   
I was asking if I can go directly to 450i AP's without having to finish 
collecting the 430's.



Mark



> On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
> <sriram.chaturv...@cambiumnetworks.com<mailto:sriram.chaturv...@cambiumnetworks.com>>
>  wrote:

>

> Hi Chuck, I was directly responding to Mark's question on 430 "upgrade" 
> project where I assumed he was eventually going to upgrade his 430 SMs to 
> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my 
> responses aren't loaded when I post here.

>

>

>> On Nov 28, 2015, at 10:28 AM, Chuck McCown 
>> <ch...@wbmfg.com<mailto:ch...@wbmfg.com>> wrote:

>>

>> "right away" sounds ominous

>>

>>

>> -Original Message- From: Sriram Chaturvedi

>> Sent: Saturday, November 28, 2015 8:00 AM

>> To: af@afmug.com<mailto:af@afmug.com>

>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

>>

>> 450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
>> away.

>>

>> Thanks,

>> Sriram

>>

>> 

>> From: Af <af-boun...@afmug.com<mailto:af-boun...@afmug.com>> on behalf of 
>> Mark Radabaugh <m...@amplex.net<mailto:m...@amplex.net>>

>> Sent: Saturday, November 28, 2015 8:24 AM

>> To: af@afmug.com<mailto:af@afmug.com>

>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

>>

>> How about 450i AP to 430 SM? I would like to start deploying 450i 
>> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 
>> SM�s swapped first?

>>

>> Mark

>>

>>

>>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
>>> <aaron.schnei...@cambiumnetworks.com<mailto:aaron.schnei...@cambiumnetworks.com>>
>>>  wrote:

>>>

>>> It should work, but at the moment I can�t recall if/when we tried this 
>>> with PTP mode.  I�ll let you know.

>>>

>>> 450i - 450 isn�t really an �interop� situation like 430 - 450 was.  
>>> 430 - 450 was quite a bit different, needing SISO to talk to MIMO with the 
>>> way we did MIMO at first (MIMO-B using both channels for data).  450i - 450 
>>> is much more similar, and we have been using that combination internally 
>>> for a long time.  It wasn�t part of the initial release of 450i due to 
>>> needing to focus on the HW release itself.

>>>

>>> I�ll be in touch on the PTP question.  It is important to allow you to 
>>> upgrade a PTP link one end at a time.

>>>

>>> Regards,

>>> -Aaron

>>>

>>>

>>>

>>>

>>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
>>> <af-boun...@afmug.com on behalf of 
>>> geo...@cbcast.com<mailto:af-boun...@afmug.com%20on%20behalf%20of%20geo...@cbcast.com>>
>>>  wrote:

>>>

>>>> I thought interop was only for PMP?

>>>>

>>>> On 11/26/2015 11:38 PM, Matt wrote:

>>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?

>>>>

>>

>

>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Ken Hohhof]

How soon will we be asking if our 450i SMs work with the new 460 APs?

More QAMs!  More frequencies!  Fiber+DC!  Active antennas!  Pull more 
rabbits out of the hat!



-Original Message- 
From: Chuck McCown

Sent: Saturday, November 28, 2015 10:36 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Just trolling... ;-)

-Original Message- 
From: Sriram Chaturvedi

Sent: Saturday, November 28, 2015 9:35 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Hi Chuck, I was directly responding to Mark�s question on 430 
�upgrade�

project where I assumed he was eventually going to upgrade his 430 SMs to
450/450i. Perhaps it was an incorrect assumption. Believe it or not, my
responses aren�t loaded when I post here.



On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:

"right away" sounds ominous


-Original Message- From: Sriram Chaturvedi
Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs out 
right away.


Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i 
instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 
SM�s swapped first?


Mark


On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:


It should work, but at the moment I can�t recall if/when we tried this 
with PTP mode.  I�ll let you know.


450i - 450 isn�t really an �interop� situation like 430 - 450 was. 
430 - 450 was quite a bit different, needing SISO to talk to MIMO with 
the way we did MIMO at first (MIMO-B using both channels for data). 
450i - 450 is much more similar, and we have been using that combination 
internally for a long time.  It wasn�t part of the initial release of 
450i due to needing to focus on the HW release itself.


I�ll be in touch on the PTP question.  It is important to allow you to 
upgrade a PTP link one end at a time.


Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:



I thought interop was only for PMP?

On 11/26/2015 11:38 PM, Matt wrote:

Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Sriram Chaturvedi]

450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
away.

Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i instead 
of 450 for 430 upgrade projects.  Do I have to get all of the 430 SM’s swapped 
first?

Mark


> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
> <aaron.schnei...@cambiumnetworks.com> wrote:
>
> It should work, but at the moment I can’t recall if/when we tried this with 
> PTP mode.  I’ll let you know.
>
> 450i - 450 isn’t really an “interop” situation like 430 - 450 was.  430 - 450 
> was quite a bit different, needing SISO to talk to MIMO with the way we did 
> MIMO at first (MIMO-B using both channels for data).  450i - 450 is much more 
> similar, and we have been using that combination internally for a long time.  
> It wasn’t part of the initial release of 450i due to needing to focus on the 
> HW release itself.
>
> I’ll be in touch on the PTP question.  It is important to allow you to 
> upgrade a PTP link one end at a time.
>
> Regards,
> -Aaron
>
>
>
>
> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" <af-boun...@afmug.com 
> on behalf of geo...@cbcast.com> wrote:
>
>> I thought interop was only for PMP?
>>
>> On 11/26/2015 11:38 PM, Matt wrote:
>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>>
>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Chuck McCown]

"right away" sounds ominous


-Original Message- 
From: Sriram Chaturvedi

Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
away.


Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i 
instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 SM�s 
swapped first?


Mark


On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:


It should work, but at the moment I can�t recall if/when we tried this 
with PTP mode.  I�ll let you know.


450i - 450 isn�t really an �interop� situation like 430 - 450 was.  430 - 
450 was quite a bit different, needing SISO to talk to MIMO with the way 
we did MIMO at first (MIMO-B using both channels for data).  450i - 450 is 
much more similar, and we have been using that combination internally for 
a long time.  It wasn�t part of the initial release of 450i due to needing 
to focus on the HW release itself.


I�ll be in touch on the PTP question.  It is important to allow you to 
upgrade a PTP link one end at a time.


Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:



I thought interop was only for PMP?

On 11/26/2015 11:38 PM, Matt wrote:

Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Chuck McCown]

Just trolling... ;-)

-Original Message- 
From: Sriram Chaturvedi

Sent: Saturday, November 28, 2015 9:35 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Hi Chuck, I was directly responding to Mark�s question on 430 �upgrade� 
project where I assumed he was eventually going to upgrade his 430 SMs to 
450/450i. Perhaps it was an incorrect assumption. Believe it or not, my 
responses aren�t loaded when I post here.




On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:

"right away" sounds ominous


-Original Message- From: Sriram Chaturvedi
Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs out 
right away.


Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i 
instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 
SM�s swapped first?


Mark


On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:


It should work, but at the moment I can�t recall if/when we tried this 
with PTP mode.  I�ll let you know.


450i - 450 isn�t really an �interop� situation like 430 - 450 was. 
430 - 450 was quite a bit different, needing SISO to talk to MIMO with 
the way we did MIMO at first (MIMO-B using both channels for data). 
 450i - 450 is much more similar, and we have been using that combination 
internally for a long time.  It wasn�t part of the initial release of 
450i due to needing to focus on the HW release itself.


I�ll be in touch on the PTP question.  It is important to allow you to 
upgrade a PTP link one end at a time.


Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:



I thought interop was only for PMP?

On 11/26/2015 11:38 PM, Matt wrote:

Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Sriram Chaturvedi]

Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade” project 
where I assumed he was eventually going to upgrade his 430 SMs to 450/450i. 
Perhaps it was an incorrect assumption. Believe it or not, my responses aren’t 
loaded when I post here. 


> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
> 
> "right away" sounds ominous
> 
> 
> -Original Message- From: Sriram Chaturvedi
> Sent: Saturday, November 28, 2015 8:00 AM
> To: af@afmug.com
> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
> 
> 450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
> away.
> 
> Thanks,
> Sriram
> 
> 
> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
> Sent: Saturday, November 28, 2015 8:24 AM
> To: af@afmug.com
> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
> 
> How about 450i AP to 430 SM? I would like to start deploying 450i instead 
> of 450 for 430 upgrade projects.  Do I have to get all of the 430 SM�s 
> swapped first?
> 
> Mark
> 
> 
>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
>> <aaron.schnei...@cambiumnetworks.com> wrote:
>> 
>> It should work, but at the moment I can�t recall if/when we tried this 
>> with PTP mode.  I�ll let you know.
>> 
>> 450i - 450 isn�t really an �interop� situation like 430 - 450 was.  
>> 430 - 450 was quite a bit different, needing SISO to talk to MIMO with the 
>> way we did MIMO at first (MIMO-B using both channels for data).  450i - 450 
>> is much more similar, and we have been using that combination internally for 
>> a long time.  It wasn�t part of the initial release of 450i due to needing 
>> to focus on the HW release itself.
>> 
>> I�ll be in touch on the PTP question.  It is important to allow you to 
>> upgrade a PTP link one end at a time.
>> 
>> Regards,
>> -Aaron
>> 
>> 
>> 
>> 
>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" <af-boun...@afmug.com 
>> on behalf of geo...@cbcast.com> wrote:
>> 
>>> I thought interop was only for PMP?
>>> 
>>> On 11/26/2015 11:38 PM, Matt wrote:
>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>>> 
> 

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Mark Radabaugh]

How about 450i AP to 430 SM? I would like to start deploying 450i instead 
of 450 for 430 upgrade projects.  Do I have to get all of the 430 SM’s swapped 
first?

Mark


> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
>  wrote:
> 
> It should work, but at the moment I can’t recall if/when we tried this with 
> PTP mode.  I’ll let you know.  
> 
> 450i - 450 isn’t really an “interop” situation like 430 - 450 was.  430 - 450 
> was quite a bit different, needing SISO to talk to MIMO with the way we did 
> MIMO at first (MIMO-B using both channels for data).  450i - 450 is much more 
> similar, and we have been using that combination internally for a long time.  
> It wasn’t part of the initial release of 450i due to needing to focus on the 
> HW release itself.
> 
> I’ll be in touch on the PTP question.  It is important to allow you to 
> upgrade a PTP link one end at a time.
> 
> Regards,
> -Aaron
> 
> 
> 
> 
> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup"  on behalf of geo...@cbcast.com> wrote:
> 
>> I thought interop was only for PMP?
>> 
>> On 11/26/2015 11:38 PM, Matt wrote:
>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>> 
> 

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Mark Radabaugh]

We have a number of towers to convert from 4 450’s with 90 degree sectors to 6 
AP’s with 60 degree sectors.   Most of these are already at 80-90% 450 SM’s.   
I was asking if I can go directly to 450i AP’s without having to finish 
collecting the 430’s. 

Mark

> On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
> <sriram.chaturv...@cambiumnetworks.com> wrote:
> 
> Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade” 
> project where I assumed he was eventually going to upgrade his 430 SMs to 
> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my 
> responses aren’t loaded when I post here. 
> 
> 
>> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
>> 
>> "right away" sounds ominous
>> 
>> 
>> -Original Message- From: Sriram Chaturvedi
>> Sent: Saturday, November 28, 2015 8:00 AM
>> To: af@afmug.com
>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>> 
>> 450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
>> away.
>> 
>> Thanks,
>> Sriram
>> 
>> 
>> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
>> Sent: Saturday, November 28, 2015 8:24 AM
>> To: af@afmug.com
>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>> 
>> How about 450i AP to 430 SM? I would like to start deploying 450i 
>> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 
>> SM�s swapped first?
>> 
>> Mark
>> 
>> 
>>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
>>> <aaron.schnei...@cambiumnetworks.com> wrote:
>>> 
>>> It should work, but at the moment I can�t recall if/when we tried this 
>>> with PTP mode.  I�ll let you know.
>>> 
>>> 450i - 450 isn�t really an �interop� situation like 430 - 450 was.  
>>> 430 - 450 was quite a bit different, needing SISO to talk to MIMO with the 
>>> way we did MIMO at first (MIMO-B using both channels for data).  450i - 450 
>>> is much more similar, and we have been using that combination internally 
>>> for a long time.  It wasn�t part of the initial release of 450i due to 
>>> needing to focus on the HW release itself.
>>> 
>>> I�ll be in touch on the PTP question.  It is important to allow you to 
>>> upgrade a PTP link one end at a time.
>>> 
>>> Regards,
>>> -Aaron
>>> 
>>> 
>>> 
>>> 
>>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
>>> <af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:
>>> 
>>>> I thought interop was only for PMP?
>>>> 
>>>> On 11/26/2015 11:38 PM, Matt wrote:
>>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>>>> 
>> 
> 
> 

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Ken Hohhof]

The other possibility would be to offer a super cheap tier for people who 
don't want to watch video, like maybe just for the kids to do homework.  If 
the customer radio was essentially free, it might become feasible to sell 
something like 1M service for $20 or $25/mo.  We still have some older 
customers who literally just use it to check email, don't even know how to 
do anything else.  They end up paying the same as people on the 3M tier who 
watch 250GB of Netflix per month.



-Original Message- 
From: Mark Radabaugh

Sent: Saturday, November 28, 2015 5:27 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Very much like that already.

We watch frame utilization and as it gets high we hunt down high usage 430's 
and swap those out, and fix any 450's running with poor signals.


There isn't a lot of point to swapping out low usage 430's so it's nice that 
we are able to leave them if we decide to deploy 450i


Mark


On Nov 28, 2015, at 5:40 PM, George Skorup <geo...@cbcast.com> wrote:

I imagine at some point, the 430 SMs will be like the old P8 SMs. You will 
want to get them off of the network to keep the overall sector capacity in 
check.



On 11/28/2015 1:05 PM, Sriram Chaturvedi wrote:
Yes you can, Mark.


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 12:35 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

We have a number of towers to convert from 4 450�s with 90 degree 
sectors to 6 AP�s with 60 degree sectors.   Most of these are already 
at 80-90% 450 SM�s.   I was asking if I can go directly to 450i AP�s 
without having to finish collecting the 430�s.


Mark

On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
<sriram.chaturv...@cambiumnetworks.com> wrote:


Hi Chuck, I was directly responding to Mark�s question on 430 
�upgrade� project where I assumed he was eventually going to upgrade 
his 430 SMs to 450/450i. Perhaps it was an incorrect assumption. Believe 
it or not, my responses aren�t loaded when I post here.




On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:

"right away" sounds ominous


-Original Message- From: Sriram Chaturvedi
Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs out 
right away.


Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i 
instead of 450 for 430 upgrade projects.  Do I have to get all of the 
430 SM�s swapped first?


Mark


On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:


It should work, but at the moment I can�t recall if/when we tried 
this with PTP mode.  I�ll let you know.


450i - 450 isn�t really an �interop� situation like 430 - 450 
was.  430 - 450 was quite a bit different, needing SISO to talk to 
MIMO with the way we did MIMO at first (MIMO-B using both channels for 
data).  450i - 450 is much more similar, and we have been using that 
combination internally for a long time.  It wasn�t part of the 
initial release of 450i due to needing to focus on the HW release 
itself.


I�ll be in touch on the PTP question.  It is important to allow you 
to upgrade a PTP link one end at a time.


Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:


I thought interop was only for PMP?


On 11/26/2015 11:38 PM, Matt wrote:
Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[George Skorup]

But the problem remains. That P8/430/low mod 450 kills the sector 
efficiency every time they talk / the AP talks to them. Maybe the thing 
Aaron was just talking about (air-time scheduling or de-prioritizing low 
mod SMs) could help.


On 11/28/2015 5:42 PM, Ken Hohhof wrote:
The other possibility would be to offer a super cheap tier for people 
who don't want to watch video, like maybe just for the kids to do 
homework.  If the customer radio was essentially free, it might become 
feasible to sell something like 1M service for $20 or $25/mo.  We 
still have some older customers who literally just use it to check 
email, don't even know how to do anything else.  They end up paying 
the same as people on the 3M tier who watch 250GB of Netflix per month.



-Original Message- From: Mark Radabaugh
Sent: Saturday, November 28, 2015 5:27 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

Very much like that already.

We watch frame utilization and as it gets high we hunt down high usage 
430's and swap those out, and fix any 450's running with poor signals.


There isn't a lot of point to swapping out low usage 430's so it's 
nice that we are able to leave them if we decide to deploy 450i


Mark


On Nov 28, 2015, at 5:40 PM, George Skorup <geo...@cbcast.com> wrote:

I imagine at some point, the 430 SMs will be like the old P8 SMs. You 
will want to get them off of the network to keep the overall sector 
capacity in check.



On 11/28/2015 1:05 PM, Sriram Chaturvedi wrote:
Yes you can, Mark.


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 12:35 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

We have a number of towers to convert from 4 450�s with 90 degree 
sectors to 6 AP�s with 60 degree sectors.   Most of these are 
already at 80-90% 450 SM�s.   I was asking if I can go directly to 
450i AP�s without having to finish collecting the 430�s.


Mark

On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
<sriram.chaturv...@cambiumnetworks.com> wrote:


Hi Chuck, I was directly responding to Mark�s question on 430 
�upgrade� project where I assumed he was eventually going to 
upgrade his 430 SMs to 450/450i. Perhaps it was an incorrect 
assumption. Believe it or not, my responses aren�t loaded when I 
post here.




On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:

"right away" sounds ominous


-Original Message- From: Sriram Chaturvedi
Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs 
out right away.


Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh 
<m...@amplex.net>

Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 
450i instead of 450 for 430 upgrade projects. Do I have to get all 
of the 430 SM�s swapped first?


Mark


On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:


It should work, but at the moment I can�t recall if/when we 
tried this with PTP mode.  I�ll let you know.


450i - 450 isn�t really an �interop� situation like 430 - 
450 was.  430 - 450 was quite a bit different, needing SISO to 
talk to MIMO with the way we did MIMO at first (MIMO-B using both 
channels for data).  450i - 450 is much more similar, and we have 
been using that combination internally for a long time. It 
wasn�t part of the initial release of 450i due to needing to 
focus on the HW release itself.


I�ll be in touch on the PTP question.  It is important to allow 
you to upgrade a PTP link one end at a time.


Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
<af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:


I thought interop was only for PMP?


On 11/26/2015 11:38 PM, Matt wrote:
Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Sriram Chaturvedi]

Yes you can, Mark. 


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
Sent: Saturday, November 28, 2015 12:35 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

We have a number of towers to convert from 4 450’s with 90 degree sectors to 6 
AP’s with 60 degree sectors.   Most of these are already at 80-90% 450 SM’s.   
I was asking if I can go directly to 450i AP’s without having to finish 
collecting the 430’s.

Mark

> On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
> <sriram.chaturv...@cambiumnetworks.com> wrote:
>
> Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade” 
> project where I assumed he was eventually going to upgrade his 430 SMs to 
> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my 
> responses aren’t loaded when I post here.
>
>
>> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
>>
>> "right away" sounds ominous
>>
>>
>> -Original Message- From: Sriram Chaturvedi
>> Sent: Saturday, November 28, 2015 8:00 AM
>> To: af@afmug.com
>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>>
>> 450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
>> away.
>>
>> Thanks,
>> Sriram
>>
>> 
>> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
>> Sent: Saturday, November 28, 2015 8:24 AM
>> To: af@afmug.com
>> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>>
>> How about 450i AP to 430 SM? I would like to start deploying 450i 
>> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430 
>> SM�s swapped first?
>>
>> Mark
>>
>>
>>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
>>> <aaron.schnei...@cambiumnetworks.com> wrote:
>>>
>>> It should work, but at the moment I can�t recall if/when we tried this 
>>> with PTP mode.  I�ll let you know.
>>>
>>> 450i - 450 isn�t really an �interop� situation like 430 - 450 was.  
>>> 430 - 450 was quite a bit different, needing SISO to talk to MIMO with the 
>>> way we did MIMO at first (MIMO-B using both channels for data).  450i - 450 
>>> is much more similar, and we have been using that combination internally 
>>> for a long time.  It wasn�t part of the initial release of 450i due to 
>>> needing to focus on the HW release itself.
>>>
>>> I�ll be in touch on the PTP question.  It is important to allow you to 
>>> upgrade a PTP link one end at a time.
>>>
>>> Regards,
>>> -Aaron
>>>
>>>
>>>
>>>
>>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" 
>>> <af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:
>>>
>>>> I thought interop was only for PMP?
>>>>
>>>> On 11/26/2015 11:38 PM, Matt wrote:
>>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>>>>
>>
>
>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[huge uge]

Hello Chuck,
a bit off subject for most posts Ive seen here,  i was trying to do the
Cambium 13.4, pmp 100 update for our equipment (11/09/15), I keep getting
this message:

 "Error occurred while updating device: AP-DES: null 11/15/15 03:05:58
WARN: Host:  . . . .   ;ESN: 0A003E910EBE;Message: Invalid File
Image(status:211).

 and another freakish event took place  : Thanksgiving morning, a raven was
pecking at our Memory Link GHR 5011 timing slave/ backhaul, and succeeded
at knocking the antenna off of the unit. I tried repairing the connector
(the keeper/ internal snap ring was dislodged from the collar) but the stub
extension will not stay in position once the winds here pick up.  I also do
not know how to access the Memory Link unit, since the previous events I no
longer can access any equipment downstream from  T 1 ( T 2 and T 3 ), If I
am on site with an SM or CMM registered with T2 or T3I can access
everything downstream of T1 as long as the unit I am plugged into is
downstream of T1,  logic says : T1 and T2  have an issue with a timing
master or timing slave or both,  I don't know where to find more resources
to expand my peanut (brain) possibly due to frustration but I need to
trouble shoot this issue our network is down and Cambium generally takes
too long. so far, every instance of Cambium support has been an education
in what doesn't work,  and after 2 or three reads of the card provided
procedures I spend two to three weeks undoing their support.  Cambium
Updater could  have been the cause,  the program locked up and did nothing
for three days, which led to having restore the PC due to corrupt or
missing files, of which I am still finding.  My redheaded temper and lack
of patients has me in a spin,  any body familiar with Memory link
procedures i.e default/reset  access for configuration ? thanks  HAGD

Chedder

On Sat, Nov 28, 2015 at 10:35 AM, Mark Radabaugh <m...@amplex.net> wrote:

> We have a number of towers to convert from 4 450’s with 90 degree sectors
> to 6 AP’s with 60 degree sectors.   Most of these are already at 80-90% 450
> SM’s.   I was asking if I can go directly to 450i AP’s without having to
> finish collecting the 430’s.
>
> Mark
>
> > On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi <
> sriram.chaturv...@cambiumnetworks.com> wrote:
> >
> > Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade”
> project where I assumed he was eventually going to upgrade his 430 SMs to
> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my
> responses aren’t loaded when I post here.
> >
> >
> >> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
> >>
> >> "right away" sounds ominous
> >>
> >>
> >> -----Original Message- From: Sriram Chaturvedi
> >> Sent: Saturday, November 28, 2015 8:00 AM
> >> To: af@afmug.com
> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
> >>
> >> 450i AP will interop with 430 SMs. You don't need to swap the SMs out
> right away.
> >>
> >> Thanks,
> >> Sriram
> >>
> >> 
> >> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <
> m...@amplex.net>
> >> Sent: Saturday, November 28, 2015 8:24 AM
> >> To: af@afmug.com
> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
> >>
> >> How about 450i AP to 430 SM? I would like to start deploying 450i
> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430
> SM�s swapped first?
> >>
> >> Mark
> >>
> >>
> >>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider <
> aaron.schnei...@cambiumnetworks.com> wrote:
> >>>
> >>> It should work, but at the moment I can�t recall if/when we tried
> this with PTP mode.  I�ll let you know.
> >>>
> >>> 450i - 450 isn�t really an �interop� situation like 430 - 450
> was.  430 - 450 was quite a bit different, needing SISO to talk to MIMO
> with the way we did MIMO at first (MIMO-B using both channels for data).
> 450i - 450 is much more similar, and we have been using that combination
> internally for a long time.  It wasn�t part of the initial release of
> 450i due to needing to focus on the HW release itself.
> >>>
> >>> I�ll be in touch on the PTP question.  It is important to allow you
> to upgrade a PTP link one end at a time.
> >>>
> >>> Regards,
> >>> -Aaron
> >>>
> >>>
> >>>
> >>>
> >>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" <
> af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:
> >>>
> >>>> I thought interop was only for PMP?
> >>>>
> >>>> On 11/26/2015 11:38 PM, Matt wrote:
> >>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
> >>>>
> >>
> >
> >
>
>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[George Skorup]

I imagine at some point, the 430 SMs will be like the old P8 SMs. You 
will want to get them off of the network to keep the overall sector 
capacity in check.


On 11/28/2015 1:05 PM, Sriram Chaturvedi wrote:

Yes you can, Mark.


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
Sent: Saturday, November 28, 2015 12:35 PM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

We have a number of towers to convert from 4 450�s with 90 degree sectors to 
6 AP�s with 60 degree sectors.   Most of these are already at 80-90% 450 
SM�s.   I was asking if I can go directly to 450i AP�s without having to 
finish collecting the 430�s.

Mark


On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi 
<sriram.chaturv...@cambiumnetworks.com> wrote:

Hi Chuck, I was directly responding to Mark�s question on 430 �upgrade� 
project where I assumed he was eventually going to upgrade his 430 SMs to 
450/450i. Perhaps it was an incorrect assumption. Believe it or not, my 
responses aren�t loaded when I post here.



On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:

"right away" sounds ominous


-Original Message- From: Sriram Chaturvedi
Sent: Saturday, November 28, 2015 8:00 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

450i AP will interop with 430 SMs. You don't need to swap the SMs out right 
away.

Thanks,
Sriram


From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <m...@amplex.net>
Sent: Saturday, November 28, 2015 8:24 AM
To: af@afmug.com
Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP

How about 450i AP to 430 SM? I would like to start deploying 450i instead 
of 450 for 430 upgrade projects.  Do I have to get all of the 430 SM�s 
swapped first?

Mark



On Nov 27, 2015, at 11:21 AM, Aaron Schneider 
<aaron.schnei...@cambiumnetworks.com> wrote:

It should work, but at the moment I can�t recall if/when we tried this with 
PTP mode.  I�ll let you know.

450i - 450 isn�t really an �interop� situation like 430 - 450 was.  430 - 
450 was quite a bit different, needing SISO to talk to MIMO with the way we did 
MIMO at first (MIMO-B using both channels for data).  450i - 450 is much more 
similar, and we have been using that combination internally for a long time.  
It wasn�t part of the initial release of 450i due to needing to focus on the 
HW release itself.

I�ll be in touch on the PTP question.  It is important to allow you to 
upgrade a PTP link one end at a time.

Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" <af-boun...@afmug.com on 
behalf of geo...@cbcast.com> wrote:


I thought interop was only for PMP?

On 11/26/2015 11:38 PM, Matt wrote:

Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[huge uge]

sorry miss typed the update  13.4 DES PMP 100

On Sat, Nov 28, 2015 at 11:29 AM, huge uge <hugeuge1...@gmail.com> wrote:

> Hello Chuck,
> a bit off subject for most posts Ive seen here,  i was trying to do the
> Cambium 13.4, pmp 100 update for our equipment (11/09/15), I keep getting
> this message:
>
>  "Error occurred while updating device: AP-DES: null 11/15/15 03:05:58
> WARN: Host:  . . . .   ;ESN: 0A003E910EBE;Message: Invalid File
> Image(status:211).
>
>  and another freakish event took place  : Thanksgiving morning, a raven
> was pecking at our Memory Link GHR 5011 timing slave/ backhaul, and
> succeeded at knocking the antenna off of the unit. I tried repairing the
> connector (the keeper/ internal snap ring was dislodged from the collar)
> but the stub extension will not stay in position once the winds here pick
> up.  I also do not know how to access the Memory Link unit, since the
> previous events I no longer can access any equipment downstream from  T 1 (
> T 2 and T 3 ), If I am on site with an SM or CMM registered with T2 or T3
>I can access everything downstream of T1 as long as the unit I am
> plugged into is downstream of T1,  logic says : T1 and T2  have an issue
> with a timing master or timing slave or both,  I don't know where to find
> more resources to expand my peanut (brain) possibly due to frustration but
> I need to trouble shoot this issue our network is down and Cambium
> generally takes too long. so far, every instance of Cambium support has
> been an education in what doesn't work,  and after 2 or three reads of the
> card provided procedures I spend two to three weeks undoing their support.
> Cambium Updater could  have been the cause,  the program locked up and did
> nothing for three days, which led to having restore the PC due to corrupt
> or missing files, of which I am still finding.  My redheaded temper and
> lack of patients has me in a spin,  any body familiar with Memory link
> procedures i.e default/reset  access for configuration ? thanks  HAGD
>
> Chedder
>
> On Sat, Nov 28, 2015 at 10:35 AM, Mark Radabaugh <m...@amplex.net> wrote:
>
>> We have a number of towers to convert from 4 450’s with 90 degree sectors
>> to 6 AP’s with 60 degree sectors.   Most of these are already at 80-90% 450
>> SM’s.   I was asking if I can go directly to 450i AP’s without having to
>> finish collecting the 430’s.
>>
>> Mark
>>
>> > On Nov 28, 2015, at 11:35 AM, Sriram Chaturvedi <
>> sriram.chaturv...@cambiumnetworks.com> wrote:
>> >
>> > Hi Chuck, I was directly responding to Mark’s question on 430 “upgrade”
>> project where I assumed he was eventually going to upgrade his 430 SMs to
>> 450/450i. Perhaps it was an incorrect assumption. Believe it or not, my
>> responses aren’t loaded when I post here.
>> >
>> >
>> >> On Nov 28, 2015, at 10:28 AM, Chuck McCown <ch...@wbmfg.com> wrote:
>> >>
>> >> "right away" sounds ominous
>> >>
>> >>
>> >> -Original Message- From: Sriram Chaturvedi
>> >> Sent: Saturday, November 28, 2015 8:00 AM
>> >> To: af@afmug.com
>> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>> >>
>> >> 450i AP will interop with 430 SMs. You don't need to swap the SMs out
>> right away.
>> >>
>> >> Thanks,
>> >> Sriram
>> >>
>> >> 
>> >> From: Af <af-boun...@afmug.com> on behalf of Mark Radabaugh <
>> m...@amplex.net>
>> >> Sent: Saturday, November 28, 2015 8:24 AM
>> >> To: af@afmug.com
>> >> Subject: Re: [AFMUG] Canopy 14.1.1 Release and PTP
>> >>
>> >> How about 450i AP to 430 SM? I would like to start deploying 450i
>> instead of 450 for 430 upgrade projects.  Do I have to get all of the 430
>> SM�s swapped first?
>> >>
>> >> Mark
>> >>
>> >>
>> >>> On Nov 27, 2015, at 11:21 AM, Aaron Schneider <
>> aaron.schnei...@cambiumnetworks.com> wrote:
>> >>>
>> >>> It should work, but at the moment I can�t recall if/when we tried
>> this with PTP mode.  I�ll let you know.
>> >>>
>> >>> 450i - 450 isn�t really an �interop� situation like 430 - 450
>> was.  430 - 450 was quite a bit different, needing SISO to talk to MIMO
>> with the way we did MIMO at first (MIMO-B using both channels for data).
>> 450i - 450 is much more similar, and we have been using that combination
>> internally for a long time.  It wasn�t part of the initial release of
>> 450i due to needing to focus on the HW release itself.
>> >>>
>> >>> I�ll be in touch on the PTP question.  It is important to allow you
>> to upgrade a PTP link one end at a time.
>> >>>
>> >>> Regards,
>> >>> -Aaron
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 11/27/15, 12:09 AM, "Af on behalf of George Skorup" <
>> af-boun...@afmug.com on behalf of geo...@cbcast.com> wrote:
>> >>>
>> >>>> I thought interop was only for PMP?
>> >>>>
>> >>>> On 11/26/2015 11:38 PM, Matt wrote:
>> >>>>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>> >>>>
>> >>
>> >
>> >
>>
>>
>

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[Aaron Schneider]

It should work, but at the moment I can’t recall if/when we tried this with PTP 
mode.  I’ll let you know.  

450i - 450 isn’t really an “interop” situation like 430 - 450 was.  430 - 450 
was quite a bit different, needing SISO to talk to MIMO with the way we did 
MIMO at first (MIMO-B using both channels for data).  450i - 450 is much more 
similar, and we have been using that combination internally for a long time.  
It wasn’t part of the initial release of 450i due to needing to focus on the HW 
release itself.

I’ll be in touch on the PTP question.  It is important to allow you to upgrade 
a PTP link one end at a time.

Regards,
-Aaron




On 11/27/15, 12:09 AM, "Af on behalf of George Skorup"  wrote:

>I thought interop was only for PMP?
>
>On 11/26/2015 11:38 PM, Matt wrote:
>> Is it possible for a PTP450i master to talk to a PTP450 slave now?
>

[AFMUG] Canopy 14.1.1 Release and PTP

[Matt]

Is it possible for a PTP450i master to talk to a PTP450 slave now?

Re: [AFMUG] Canopy 14.1.1 Release and PTP

[George Skorup]

I thought interop was only for PMP?

On 11/26/2015 11:38 PM, Matt wrote:

Is it possible for a PTP450i master to talk to a PTP450 slave now?

[AFMUG] Canopy 14.1.1

[George Skorup]

I see it made it to the support site today. How about putting up 
13.2.1.3 for us with Lite APs that may want to go back?

Re: [AFMUG] Canopy 14.1.1

[Aaron Schneider]

I can help if that is necessary.  I’ll forward this on internally.  




On 11/25/15, 6:02 PM, "Af on behalf of George Skorup"  wrote:

>I see it made it to the support site today. How about putting up 
>13.2.1.3 for us with Lite APs that may want to go back?