PMP450 SM v16.1 Error Bandwidth PLL lock lost

Products PMP
1

Has anyone experienced the Error "Bandwidth PLL lock lost" printed in red at the SM?

Thanks

Art

2

Yes. Reboot makes it go away. Don't know what it is.

3
@Ryan Ray wrote:

 Don't know what it is.

PLL stand for Phase Locked Loop. It is what generates and controls the TX/RX frequency of the radio. If it becomes unlocked, radio will shut TX power off so radio is not transmitting out of band. I would definitely contact Cambium if you are seeing this error. A PLL that has lost lock is a major error in any radio. 

1 Like
4

CWB,

Thanks for your response. I will check into this with Cambium Networks.

Do you know which is the best OID to get the errors that are printed at the top of units in red?

Art

5

Art,

No, I do not. We are a semi-new WISP and have not made it to the major leagues of PMP450. We are only using the ePMP line at this time. 

I knew what a PLL was from being in the two-way radio field since a child. 

6
@Art wrote:

Has anyone experenced the Error "Bandwidth PLL lock lost" printed in red at the SM?

Thanks

Art

@Ryan Ray wrote:

Yes. Reboot makes it go away. Don't know what it is.


Art and Ryan,
This is a new warning that we added on 16.1. It's noticing that the Phase Lock Loop of the FPGA's Bandwidth PLL is going out of lock. There are multiple PLLs on the board, and this is just an internal one. It might work fine with this warning, or might be an indication of another problem.

We did not see any failures internally for this warning. So we are very interested if you or Ryan have logs of SMs in this condition. If you catch one with that message active, would you please capture http://<IP>/engineering.cgi and send it to support or me at charlie.galik@cambiumnetworks.com. 

If you have a board that is doing this continuously, we'd love to investigate further, maybe even shipping us this radio if possible.

@Art wrote:

Do you know which is the best OID to get the errors that are printed at the top of units in red?

This red warning text is currently just a web only feature. We should add an OID for this. I have opened issue CPY-16071 to track this issue internally.

Thanks for reporting this and thanks in advance for your help,
Charlie

7

With the concerns we have heard brought up and differing information we are getting we are looking at retrieving the unit and shipping it without messing with it anymore on our end once retrieved to...

Cambium Networks

c/o Dave Smudde

3800 Golf Road Suite 360

Rolling Meadows, IL 60008

The radio has the MAC address of 0a-00-3e-b6-66-42.

1 Like
8
@hammer185 wrote:

With the concerns we have heard brought up and differing information we are getting we are looking at retrieving the unit and shipping it without messing with it anymore on our end once retrieved to...

Cambium Networks

c/o Dave Smudde

3800 Golf Road Suite 360

Rolling Meadows, IL 60008

The radio has the MAC address of 0a-00-3e-b6-66-42.

Sounds good. Thanks, hammer.

9

Hi, we've just encountered this same error on SM with 16.1 It's the first we've seen, if you want we can provide you with the engineering before we reboot it.

10
@MW_WISP wrote:

Hi, we've just encountered this same error on SM with 16.1 It's the first we've seen, if you want we can provide you with the engineering before we reboot it.

Yes, please. Charlie.Galik@cambiumnetworks.com

Thanks in advance.

11

Found it again on another SM. Sent engineering.cgi

12

Ryan,

Thanks so much for sending it over. With the help all the logs, I have found a bug in my software where this can indicate a false positive for error. I have fixed the false positive and it will be in release 16.1.1.  Or if you want to test a load with this fix, I can get you an image.

There is still a chance for a true positive error, which can have this problem and will not register to an AP. We are actively investigating that issue.

Charlie

1 Like
13

Any update on this?  I just encountered my first instance of this issue.

14
@Neil Capell wrote:

Any update on this?  I just encountered my first instance of this issue.

Neil,

This issue was resolved in 16.1.1, which has been officially released.

However, note 16.1.1 does not cap MIR for SMs with NAT enabled. So we are fixing that in 16.1.1.1, which we expect to go official early next week.

Charlie

15

I’m having this issue on PTP 450 with 16.1.1, never seen it before. Causes the slave device not to register.

16

I’d submit a support ticket, sounds like you have an actual hardware issue.