subject:"\[AFMUG\] PMP450 SMs"

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread George Skorup

Losing calibration, license and config is without a doubt corrupt 
flashes. You'll probably be better off swapping them.


On 9/7/2017 11:17 AM, Darren Shea wrote:


Just wondering, if this is a problem which only bedevils me, or if 
other people are seeing it:


PMP450 SMs, running 15.0 or later f/w (itï¿½s a question right now 
whether the AP f/w is related to this, but it seems that the APs are 
usually running 13.2 f/w)


The symptom is the SM throws a bunch of "Deleting a timer since it was 
active" errors, then some other errors, then it resets to factory 
defaults and reboots (see below for typical Event log snippet). 
Sometimes, the radio loses calibration data. Because we run our 
configurations as close as possible to default in the first place, we 
can typically access the radio via ICC and reconfigure it 
appropriately without a truck. However, and this is a *huge* deal, 
some of these radios that had 10M keys are now reverting to 4M keys! 
This is going to cause us major headaches.


I have opened lines of communication with Cambium about this, but they 
are giving me their standard ï¿½we havenï¿½t heard about thisï¿½ response 
which is always their default up until they admit itï¿½s a problem and 
start to resolve it. ï¿½Have any of you encountered these issues?


Typical Event Log snippet:

09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;

09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;

09/07/2017 : 01:26:27 CST : :Forced reset;

09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


01/01/2016 : 00:00:00 UTC : :

01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li

01/01/2016 : 00:00:00 UTC :

***SYSTEM STARTUP***

System Reset Exception -- Watchdog Reset

Software Version : CANOPY 15.0.2 SM-DES

Board Type : P11

Boot Bank : 0

Board Temperature : 38 C / 101 F

Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module - 
0a-00-3e-bx-yy-zz

No valid accounts configured. Using default user account

FPGA Version : 061716

FPGA Features : DES, Sched;

01/01/2016 : 00:00:00 UTC : 
:CalParams[46,47,58,59,60,61,62,63,64,65,66,67,68,72,76,77], updated 
FPM, CalParams and FPM mismatch!


FeatureKey mismatch for FKey[1]

12/31/2015 : 18:03:37 CST : :Timezone set to CST;

09/07/2017 : 01:30:24 CST : :Time Set

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread Darren Shea

The SNMP reset lines result from a script which sends a reboot to radios under 
certain conditions, but this script does not correlate to the resetting (that 
is, it happened before the script was deployed, and on APs where the script is 
deployed, it has happened on just a tiny handful of radios which hadn't been 
rebooted by that script in over a week). The reboot command is just an snmpset 
to the .1.3.6.1.4.1.161.19.3.3.3.2.0 OID aimed at the SM through the AP. If 
that is triggering the resets, then there is a bigger problem than we realized!



-Original Message-
From: Af [mailto:af-boun...@afmug.com] On Behalf Of Larry Smith
Sent: Thursday, September 07, 2017 12:49 PM
To: af@afmug.com
Subject: Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Interesting, do not see any of these sort of errors on our 450's.
Also interesting are the SNMP lines:

> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
> 09/07/2017 : 01:26:27 CST : :Forced reset;

almost appears that some monitoring equipment is rebooting the SM

--
Larry Smith
lesm...@ecsis.net

On Thu September 7 2017 11:17, Darren Shea wrote:
> Just wondering, if this is a problem which only bedevils me, or if 
> other people are seeing it:
>
>
>
> PMP450 SMs, running 15.0 or later f/w (it's a question right now 
> whether the AP f/w is related to this, but it seems that the APs are 
> usually running 13.2 f/w)
>
>
>
> The symptom is the SM throws a bunch of "Deleting a timer since it was 
> active" errors, then some other errors, then it resets to factory 
> defaults and reboots (see below for typical Event log snippet). 
> Sometimes, the radio loses calibration data. Because we run our 
> configurations as close as possible to default in the first place, we 
> can typically access the radio via ICC and reconfigure it 
> appropriately without a truck. However, and this is a huge deal, some 
> of these radios that had 10M keys are now reverting to 4M keys! This is going 
> to cause us major headaches.
>
>
>
> I have opened lines of communication with Cambium about this, but they 
> are giving me their standard "we haven't heard about this" response 
> which is always their default up until they admit it's a problem and 
> start to resolve it.  Have any of you encountered these issues?
>
>
>
> Typical Event Log snippet:
>
>
> 09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
> CurrentTask=48
>
>
> 09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
> CurrentTask=48
>
>
> 09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
> CurrentTask=48
>
>
> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
>
> 09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
> CurrentTask=48
>
>
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
>
> 09/07/2017 : 01:26:27 CST : :Forced reset;
>
>
> 09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
> CurrentTask=48
>
>
> 01/01/2016 : 00:00:00 UTC : :
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams 
> and FPM mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li
>
>
> 01/01/2016 : 00:00:00 UTC :
>
> **SYSTEM STARTUP**
>
>
> System Reset Exception -- Watchdog Reset
>
>
> Software Version : CANOPY 15.0.2 SM-DES
>
>
> Board Type : P11
>
>
> Boot Bank : 0
>
>
> Board Temperature : 38 C / 101 F
>
>
> Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module - 
> 0a-00-

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread Larry Smith

Interesting, do not see any of these sort of errors on our 450's.
Also interesting are the SNMP lines:

> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
> 09/07/2017 : 01:26:27 CST : :Forced reset;

almost appears that some monitoring equipment is rebooting the SM

-- 
Larry Smith
lesm...@ecsis.net

On Thu September 7 2017 11:17, Darren Shea wrote:
> Just wondering, if this is a problem which only bedevils me, or if other
> people are seeing it:
>
>
>
> PMP450 SMs, running 15.0 or later f/w (it's a question right now whether
> the AP f/w is related to this, but it seems that the APs are usually
> running 13.2 f/w)
>
>
>
> The symptom is the SM throws a bunch of "Deleting a timer since it was
> active" errors, then some other errors, then it resets to factory defaults
> and reboots (see below for typical Event log snippet). Sometimes, the radio
> loses calibration data. Because we run our configurations as close as
> possible to default in the first place, we can typically access the radio
> via ICC and reconfigure it appropriately without a truck. However, and this
> is a huge deal, some of these radios that had 10M keys are now reverting to
> 4M keys! This is going to cause us major headaches.
>
>
>
> I have opened lines of communication with Cambium about this, but they are
> giving me their standard "we haven't heard about this" response which is
> always their default up until they admit it's a problem and start to
> resolve it.  Have any of you encountered these issues?
>
>
>
> Typical Event Log snippet:
>
>
> 09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
>
> 09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
>
> 09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
>
> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
>
> 09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
>
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
>
> 09/07/2017 : 01:26:27 CST : :Forced reset;
>
>
> 09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
>
> 01/01/2016 : 00:00:00 UTC : :
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams and FPM
> mismatch!
>
>
> 01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li
>
>
> 01/01/2016 : 00:00:00 UTC :
>
> **SYSTEM STARTUP**
>
>
> System Reset Exception -- Watchdog Reset
>
>
> Software Version : CANOPY 15.0.2 SM-DES
>
>
> Board Type : P11
>
>
> Boot Bank : 0
>
>
> Board Temperature : 38 C / 101 F
>
>
> Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
> 0a-00-3e-bx-yy-zz
> No valid accounts configured. Using default user account
>
>
> FPGA Version : 061716
>
>
> FPGA Features : DES, Sched;
>
> 01/01/2016 : 00:00:00 UTC :
> :CalParams[46,47,58,59,60,61,62,63,64,65,66,67,68,72,76,77], updated FPM,
>
> CalParams and FPM mismatch!
>
>
> FeatureKey mismatch for FKey[1]
>
>
> 12/31/2015 : 18:03:37 CST : :Timezone set to CST;
>
>
> 09/07/2017 : 01:30:24 CST : :Time Set

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread castarritt .

We don't have anything in the timing ports of our SMs other than the
occasional dead spider.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Sep 7, 2017 at 12:17 PM, Sean Heskett  wrote:

> is there anything connected to the timing port of these radios??
>
> -sean
>
>
> On Thu, Sep 7, 2017 at 10:17 AM, Darren Shea  wrote:
>
>> Just wondering, if this is a problem which only bedevils me, or if other
>> people are seeing it:
>>
>>
>>
>> PMP450 SMs, running 15.0 or later f/w (it’s a question right now whether
>> the AP f/w is related to this, but it seems that the APs are usually
>> running 13.2 f/w)
>>
>>
>>
>> The symptom is the SM throws a bunch of "Deleting a timer since it was
>> active" errors, then some other errors, then it resets to factory defaults
>> and reboots (see below for typical Event log snippet). Sometimes, the radio
>> loses calibration data. Because we run our configurations as close as
>> possible to default in the first place, we can typically access the radio
>> via ICC and reconfigure it appropriately without a truck. However, and this
>> is a *huge* deal, some of these radios that had 10M keys are now
>> reverting to 4M keys! This is going to cause us major headaches.
>>
>>
>>
>> I have opened lines of communication with Cambium about this, but they
>> are giving me their standard “we haven’t heard about this” response which
>> is always their default up until they admit it’s a problem and start to
>> resolve it.  Have any of you encountered these issues?
>>
>>
>>
>> Typical Event Log snippet:
>>
>> 09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
>> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>>
>> 09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
>> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>>
>> 09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
>> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>>
>> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
>>
>> 09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
>> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>>
>> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
>>
>> 09/07/2017 : 01:26:27 CST : :Forced reset;
>>
>> 09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
>> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>>
>> 01/01/2016 : 00:00:00 UTC : :
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams and
>> FPM mismatch!
>>
>> 01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li
>>
>> 01/01/2016 : 00:00:00 UTC :
>>
>> ***SYSTEM STARTUP***
>>
>> System Reset Exception -- Watchdog Reset
>>
>> Software Version : CANOPY 15.0.2 SM-DES
>>
>> Board Type : P11
>>
>> Boot Bank : 0
>>
>> Board Temperature : 38 C / 101 F
>>
>> Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
>> 0a-00-3e-bx-yy-zz
>> No valid accounts configured. Using default user account
>>
>> FPGA Version : 061716
>>
>> FPGA Features : DES, Sched;
>>
>> 01/01/2016 : 00:00:00 UTC : 
>> :CalParams[46,47,58,59,60,61,62,63,64,65,66,67,68,72,76,77],
>> updated FPM, CalParams and FPM mismatch!
>>
>> FeatureKey mismatch for FKey[1]
>>
>> 12/31/2015 : 18:03:37 CST : :Timezone set to CST;
>>
>> 09/07/2017 : 01:30:24 CST : :Time Set
>>
>>
>>
>
>

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread castarritt .

I know of at least one SM with the new switching poe adapter that has done
this, so I do not suspect the power adapter is our problem, but thanks for
the input.


On Thu, Sep 7, 2017 at 11:24 AM, Bill Prince  wrote:

> I have seen this when we used to use the old transformer-style POE
> injectors. If there was a power brown-out, the units would sometimes reset
> to factory when the power hovered at/near the power supply's ability to
> regulate working voltage to the logic circuits.
>
> We see it much less since the advent of switching P/S POE injectors.
>
> So what I'm suggesting is to examine the power on the POE and see if there
> is an issue there.
>
>
> bp
> 
>
>
> On 9/7/2017 9:17 AM, Darren Shea wrote:
>
> Just wondering, if this is a problem which only bedevils me, or if other
> people are seeing it:
>
> ï¿½
>
> PMP450 SMs, running 15.0 or later f/w (itï¿½s a question right now whether
> the AP f/w is related to this, but it seems that the APs are usually
> running 13.2 f/w)
>
> ï¿½
>
> The symptom is the SM throws a bunch of "Deleting a timer since it was
> active" errors, then some other errors, then it resets to factory defaults
> and reboots (see below for typical Event log snippet). Sometimes, the radio
> loses calibration data. Because we run our configurations as close as
> possible to default in the first place, we can typically access the radio
> via ICC and reconfigure it appropriately without a truck. However, and this
> is a *huge* deal, some of these radios that had 10M keys are now
> reverting to 4M keys! This is going to cause us major headaches.
>
> ï¿½
>
> I have opened lines of communication with Cambium about this, but they are
> giving me their standard ï¿½we havenï¿½t heard about thisï¿½ response which
> is always their default up until they admit itï¿½s a problem and start to
> resolve it. ï¿½Have any of you encountered these issues?
>
> ï¿½
>
> Typical Event Log snippet:
>
> 09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
> 09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
> 09/07/2017 : 01:26:27 CST : :Forced reset;
>
> 09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 01/01/2016 : 00:00:00 UTC : :
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li
>
> 01/01/2016 : 00:00:00 UTC :
>
> ***SYSTEM STARTUP***
>
> System Reset Exception --ï¿½Watchdog Reset
>
> Software Version : CANOPY 15.0.2 SM-DES
>
> Board Type : P11
>
> Boot Bank : 0
>
> Board Temperature : 38 C / 101 F
>
> Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
> 0a-00-3e-bx-yy-zz
> No valid accounts configured. Using default user account
>
> FPGA Version : 061716
>
> FPGA Features : DES, Sched;
>
> 01/01/2016 : 00:00:00 UTC : :CalParams[46,47,58,59,60,61,
> 62,63,64,65,66,67,68,72,76,77], updated FPM, CalParams and FPM mismatch!
>
> FeatureKey mismatch for FKey[1]
>
> 12/31/2015 : 18:03:37 CST : :Timezone set to CST;
>
> 09/07/2017 : 01:30:24 CST : :Time Set
>
> ï¿½
>
>
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread Sean Heskett

is there anything connected to the timing port of these radios??

-sean


On Thu, Sep 7, 2017 at 10:17 AM, Darren Shea  wrote:

> Just wondering, if this is a problem which only bedevils me, or if other
> people are seeing it:
>
>
>
> PMP450 SMs, running 15.0 or later f/w (it’s a question right now whether
> the AP f/w is related to this, but it seems that the APs are usually
> running 13.2 f/w)
>
>
>
> The symptom is the SM throws a bunch of "Deleting a timer since it was
> active" errors, then some other errors, then it resets to factory defaults
> and reboots (see below for typical Event log snippet). Sometimes, the radio
> loses calibration data. Because we run our configurations as close as
> possible to default in the first place, we can typically access the radio
> via ICC and reconfigure it appropriately without a truck. However, and this
> is a *huge* deal, some of these radios that had 10M keys are now
> reverting to 4M keys! This is going to cause us major headaches.
>
>
>
> I have opened lines of communication with Cambium about this, but they are
> giving me their standard “we haven’t heard about this” response which is
> always their default up until they admit it’s a problem and start to
> resolve it.  Have any of you encountered these issues?
>
>
>
> Typical Event Log snippet:
>
> 09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
> 09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;
>
> 09/07/2017 : 01:26:27 CST : :Forced reset;
>
> 09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
> TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48
>
> 01/01/2016 : 00:00:00 UTC : :
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams and
> FPM mismatch!
>
> 01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li
>
> 01/01/2016 : 00:00:00 UTC :
>
> ***SYSTEM STARTUP***
>
> System Reset Exception -- Watchdog Reset
>
> Software Version : CANOPY 15.0.2 SM-DES
>
> Board Type : P11
>
> Boot Bank : 0
>
> Board Temperature : 38 C / 101 F
>
> Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
> 0a-00-3e-bx-yy-zz
> No valid accounts configured. Using default user account
>
> FPGA Version : 061716
>
> FPGA Features : DES, Sched;
>
> 01/01/2016 : 00:00:00 UTC : :CalParams[46,47,58,59,60,61,
> 62,63,64,65,66,67,68,72,76,77], updated FPM, CalParams and FPM mismatch!
>
> FeatureKey mismatch for FKey[1]
>
> 12/31/2015 : 18:03:37 CST : :Timezone set to CST;
>
> 09/07/2017 : 01:30:24 CST : :Time Set
>
>
>

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread Bill Prince

I have seen this when we used to use the old transformer-style POE 
injectors. If there was a power brown-out, the units would sometimes 
reset to factory when the power hovered at/near the power supply's 
ability to regulate working voltage to the logic circuits.


We see it much less since the advent of switching P/S POE injectors.

So what I'm suggesting is to examine the power on the POE and see if 
there is an issue there.



bp


On 9/7/2017 9:17 AM, Darren Shea wrote:


Just wondering, if this is a problem which only bedevils me, or if 
other people are seeing it:


PMP450 SMs, running 15.0 or later f/w (itï¿½s a question right now 
whether the AP f/w is related to this, but it seems that the APs are 
usually running 13.2 f/w)


The symptom is the SM throws a bunch of "Deleting a timer since it was 
active" errors, then some other errors, then it resets to factory 
defaults and reboots (see below for typical Event log snippet). 
Sometimes, the radio loses calibration data. Because we run our 
configurations as close as possible to default in the first place, we 
can typically access the radio via ICC and reconfigure it 
appropriately without a truck. However, and this is a *huge* deal, 
some of these radios that had 10M keys are now reverting to 4M keys! 
This is going to cause us major headaches.


I have opened lines of communication with Cambium about this, but they 
are giving me their standard ï¿½we havenï¿½t heard about thisï¿½ response 
which is always their default up until they admit itï¿½s a problem and 
start to resolve it. ï¿½Have any of you encountered these issues?


Typical Event Log snippet:

09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;

09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;

09/07/2017 : 01:26:27 CST : :Forced reset;

09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T), 
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, 
CurrentTask=48


01/01/2016 : 00:00:00 UTC : :

01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams 
and FPM mismatch!


01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li

01/01/2016 : 00:00:00 UTC :

***SYSTEM STARTUP***

System Reset Exception -- Watchdog Reset

Software Version : CANOPY 15.0.2 SM-DES

Board Type : P11

Boot Bank : 0

Board Temperature : 38 C / 101 F

Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module - 
0a-00-3e-bx-yy-zz

No valid accounts configured. Using default user account

FPGA Version : 061716

FPGA Features : DES, Sched;

01/01/2016 : 00:00:00 UTC : 
:CalParams[46,47,58,59,60,61,62,63,64,65,66,67,68,72,76,77], updated 
FPM, CalParams and FPM mismatch!


FeatureKey mismatch for FKey[1]

12/31/2015 : 18:03:37 CST : :Timezone set to CST;

09/07/2017 : 01:30:24 CST : :Time Set

[AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

2017-09-07 Thread Darren Shea

Just wondering, if this is a problem which only bedevils me, or if other
people are seeing it:

 

PMP450 SMs, running 15.0 or later f/w (it's a question right now whether the
AP f/w is related to this, but it seems that the APs are usually running
13.2 f/w)

 

The symptom is the SM throws a bunch of "Deleting a timer since it was
active" errors, then some other errors, then it resets to factory defaults
and reboots (see below for typical Event log snippet). Sometimes, the radio
loses calibration data. Because we run our configurations as close as
possible to default in the first place, we can typically access the radio
via ICC and reconfigure it appropriately without a truck. However, and this
is a huge deal, some of these radios that had 10M keys are now reverting to
4M keys! This is going to cause us major headaches.

 

I have opened lines of communication with Cambium about this, but they are
giving me their standard "we haven't heard about this" response which is
always their default up until they admit it's a problem and start to resolve
it.  Have any of you encountered these issues?

 

Typical Event Log snippet:


09/07/2017 : 01:26:19 CST : :Deleting a timer since it was active (T),
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48


09/07/2017 : 01:26:21 CST : :Deleting a timer since it was active (T),
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48


09/07/2017 : 01:26:23 CST : :Deleting a timer since it was active (T),
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48


09/07/2017 : 01:26:25 CST : :SNMP user; user=snmp; Reboot from SNMP;


09/07/2017 : 01:26:25 CST : :Deleting a timer since it was active (T),
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48


09/07/2017 : 01:26:27 CST : :SNMP user; user=snmp; Reboot from SNMP;


09/07/2017 : 01:26:27 CST : :Forced reset;


09/07/2017 : 01:26:27 CST : :Deleting a timer since it was active (T),
TimerId=0x5fa0c0 (0xac325c), TimerEvent=0x8, TimerTaskId=48, CurrentTask=48


01/01/2016 : 00:00:00 UTC : :


01/01/1970 : 00:00:00 UTC : :CalParams[46], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[47], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[58], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[59], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[60], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[61], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[62], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : :CalParams[63], updating FPM, CalParams and FPM
mismatch!


01/01/1970 : 00:00:00 UTC : File src/cal_params.c : Li


01/01/2016 : 00:00:00 UTC :

**SYSTEM STARTUP**


System Reset Exception -- Watchdog Reset


Software Version : CANOPY 15.0.2 SM-DES


Board Type : P11


Boot Bank : 0


Board Temperature : 38 C / 101 F


Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module -
0a-00-3e-bx-yy-zz
No valid accounts configured. Using default user account


FPGA Version : 061716


FPGA Features : DES, Sched;


01/01/2016 : 00:00:00 UTC :
:CalParams[46,47,58,59,60,61,62,63,64,65,66,67,68,72,76,77], updated FPM,
CalParams and FPM mismatch!


FeatureKey mismatch for FKey[1]


12/31/2015 : 18:03:37 CST : :Timezone set to CST;


09/07/2017 : 01:30:24 CST : :Time Set

Re: [AFMUG] PMP450 SMs

2017-04-26 Thread Matt

Can you get replacement parts such as mounting and dish for 450d?



On Tue, Jan 3, 2017 at 1:31 PM, Timothy Steele  wrote:
> The 450d is better with a dish there is a little RF that falls off the back
> of a reflector dish with the 450d being inner feed you get rid of that issue
> resulting in much better performance even if you swap a dish for a 450d and
> signal stays the same you will still see better link caps from the 450d I
> have noticed
>
>
> On Tue, Jan 3, 2017, 2:26 PM Jeff Broadwick - Lists 
> wrote:
>>
>> 40 Mbps key with the latest firmware...for the 20 Meg price.  I have a
>> number of Cambium customer's that have settled on the 450d as their primary
>> SM of choice.
>>
>> Jeff Broadwick
>> ConVergence Technologies, Inc.
>> 312-205-2519 Office
>> 574-220-7826 Cell
>> jbroadw...@converge-tech.com
>>
>> On Jan 3, 2017, at 2:23 PM, Josh Luthman 
>> wrote:
>>
>> I've heard some reports that there's a 1-3 dbi difference between one and
>> the other.  I think it's the same in the grand scheme of things.
>>
>> The biggest thing is the 450d comes with a better license.
>>
>>
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> On Tue, Jan 3, 2017 at 2:03 PM, Peter Kranz  wrote:
>>>
>>> I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs
>>> w/ RCL-2 dishes.. We estimated an overall system gain of 25 dbi.
>>>
>>>
>>>
>>> The PMP450d spec sheet indicates 25 dbi as well.
>>>
>>>
>>>
>>> Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly
>>> comment on gain differences.
>>>
>>>
>>>
>>> Also am I correct in that PMP450d has a better processor than the
>>> original PMP450 SMs?
>>>
>>>
>>>
>>> Peter Kranz
>>>
>>> www.UnwiredLtd.com
>>> Desk: 510-868-1614 x100
>>> Mobile: 510-207-
>>> pkr...@unwiredltd.com

Re: [AFMUG] PMP450 SMs

2017-01-03 Thread Josh Luthman

It's cute to see PMP450 catching up with ePMP.


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

On Tue, Jan 3, 2017 at 2:26 PM, Jeff Broadwick - Lists 
wrote:

> 40 Mbps key with the latest firmware...for the 20 Meg price.  I have a
> number of Cambium customer's that have settled on the 450d as their primary
> SM of choice.
>
> Jeff Broadwick
> ConVergence Technologies, Inc.
> 312-205-2519 <(312)%20205-2519> Office
> 574-220-7826 <(574)%20220-7826> Cell
> jbroadw...@converge-tech.com
>
> On Jan 3, 2017, at 2:23 PM, Josh Luthman 
> wrote:
>
> I've heard some reports that there's a 1-3 dbi difference between one and
> the other.  I think it's the same in the grand scheme of things.
>
> The biggest thing is the 450d comes with a better license.
>
>
> Josh Luthman
> Office: 937-552-2340 <(937)%20552-2340>
> Direct: 937-552-2343 <(937)%20552-2343>
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jan 3, 2017 at 2:03 PM, Peter Kranz  wrote:
>
>> I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs
>> w/ RCL-2 dishes.. We estimated an overall system gain of 25 dbi.
>>
>>
>>
>> The PMP450d spec sheet indicates 25 dbi as well.
>>
>>
>>
>> Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly
>> comment on gain differences.
>>
>>
>>
>> Also am I correct in that PMP450d has a better processor than the
>> original PMP450 SMs?
>>
>>
>>
>>
>> *Peter Kranz*www.UnwiredLtd.com 
>> Desk: 510-868-1614 x100 <(510)%20868-1614>
>> Mobile: 510-207- <(510)%20207->
>> pkr...@unwiredltd.com
>>
>>
>>
>
>

Re: [AFMUG] PMP450 SMs

2017-01-03 Thread Timothy Steele

The 450d is better with a dish there is a little RF that falls off the back
of a reflector dish with the 450d being inner feed you get rid of that
issue resulting in much better performance even if you swap a dish for a
450d and signal stays the same you will still see better link caps from the
450d I have noticed

On Tue, Jan 3, 2017, 2:26 PM Jeff Broadwick - Lists 
wrote:

> 40 Mbps key with the latest firmware...for the 20 Meg price.  I have a
> number of Cambium customer's that have settled on the 450d as their primary
> SM of choice.
>
> Jeff Broadwick
> ConVergence Technologies, Inc.
> 312-205-2519 Office
> 574-220-7826 Cell
> jbroadw...@converge-tech.com
>
> On Jan 3, 2017, at 2:23 PM, Josh Luthman 
> wrote:
>
> I've heard some reports that there's a 1-3 dbi difference between one and
> the other.  I think it's the same in the grand scheme of things.
>
> The biggest thing is the 450d comes with a better license.
>
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Tue, Jan 3, 2017 at 2:03 PM, Peter Kranz  wrote:
>
> I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs
> w/ RCL-2 dishes.. We estimated an overall system gain of 25 dbi.
>
>
>
> The PMP450d spec sheet indicates 25 dbi as well.
>
>
>
> Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly
> comment on gain differences.
>
>
>
> Also am I correct in that PMP450d has a better processor than the original
> PMP450 SMs?
>
>
>
>
> *Peter Kranz*
>
> www.UnwiredLtd.com 
> Desk: 510-868-1614 x100 <(510)%20868-1614>
> Mobile: 510-207- <(510)%20207->
> pkr...@unwiredltd.com
>
>

Re: [AFMUG] PMP450 SMs

2017-01-03 Thread Jeff Broadwick - Lists

40 Mbps key with the latest firmware...for the 20 Meg price.  I have a number 
of Cambium customer's that have settled on the 450d as their primary SM of 
choice.

Jeff Broadwick
ConVergence Technologies, Inc.
312-205-2519 Office
574-220-7826 Cell
jbroadw...@converge-tech.com

> On Jan 3, 2017, at 2:23 PM, Josh Luthman  wrote:
> 
> I've heard some reports that there's a 1-3 dbi difference between one and the 
> other.  I think it's the same in the grand scheme of things.
> 
> The biggest thing is the 450d comes with a better license.
> 
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
>> On Tue, Jan 3, 2017 at 2:03 PM, Peter Kranz  wrote:
>> I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs w/ 
>> RCL-2 dishes.. We estimated an overall system gain of 25 dbi.
>> 
>>  
>> 
>> The PMP450d spec sheet indicates 25 dbi as well.
>> 
>>  
>> 
>> Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly comment 
>> on gain differences.
>> 
>>  
>> 
>> Also am I correct in that PMP450d has a better processor than the original 
>> PMP450 SMs?
>> 
>>  
>> 
>> Peter Kranz
>> www.UnwiredLtd.com
>> Desk: 510-868-1614 x100
>> Mobile: 510-207-
>> pkr...@unwiredltd.com
>> 
>>  
>> 
>

Re: [AFMUG] PMP450 SMs

2017-01-03 Thread George Skorup

The 450d is pretty much the same gain as a standard SM + 27RD style 
reflector. Maybe 1dB better.


The 450d board is exactly the same as a standard SM. Integrated patch 
and all. The only difference is in software. It's locked to 24 or 25dBi 
total antenna system gain.


The new wideband 5GHz SM coming this year will have more CPU horsepower.

On 1/3/2017 1:03 PM, Peter Kranz wrote:


I have not bought PMP450 SMs in some time.. we had a stock of PMP450 
SMs w/ RCL-2 dishes.. We estimated an overall system gain of 25 dbi.


The PMP450d spec sheet indicates 25 dbi as well.

Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly 
comment on gain differences.


Also am I correct in that PMP450d has a better processor than the 
original PMP450 SMs?


*Peter Kranz
*www.UnwiredLtd.com 
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

Re: [AFMUG] PMP450 SMs

2017-01-03 Thread Josh Luthman

I've heard some reports that there's a 1-3 dbi difference between one and
the other.  I think it's the same in the grand scheme of things.

The biggest thing is the 450d comes with a better license.


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

On Tue, Jan 3, 2017 at 2:03 PM, Peter Kranz  wrote:

> I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs
> w/ RCL-2 dishes.. We estimated an overall system gain of 25 dbi.
>
>
>
> The PMP450d spec sheet indicates 25 dbi as well.
>
>
>
> Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly
> comment on gain differences.
>
>
>
> Also am I correct in that PMP450d has a better processor than the original
> PMP450 SMs?
>
>
>
>
> *Peter Kranz*www.UnwiredLtd.com 
> Desk: 510-868-1614 x100 <(510)%20868-1614>
> Mobile: 510-207- <(510)%20207->
> pkr...@unwiredltd.com
>
>
>

[AFMUG] PMP450 SMs

2017-01-03 Thread Peter Kranz

I have not bought PMP450 SMs in some time.. we had a stock of PMP450 SMs w/
RCL-2 dishes.. We estimated an overall system gain of 25 dbi. 

 

The PMP450d spec sheet indicates 25 dbi as well.

 

Has anyone compared the PMP450+RCL-2 with a PMP450d and can quickly comment
on gain differences.

 

Also am I correct in that PMP450d has a better processor than the original
PMP450 SMs?

 

Peter Kranz
www.UnwiredLtd.com  
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

[AFMUG] PMP450 SMs resetting to Factory Defaults? Anyone?

Re: [AFMUG] PMP450 SMs

Re: [AFMUG] PMP450 SMs

Re: [AFMUG] PMP450 SMs

Re: [AFMUG] PMP450 SMs

Re: [AFMUG] PMP450 SMs

Re: [AFMUG] PMP450 SMs

[AFMUG] PMP450 SMs

15 matches

Site Navigation

Mail list logo

Footer information