Re: [AFMUG] 450 SM ADI communication failure
Ken Brian, Yes, ADI communication failure is a hardware issue and the board should be RMA'd. Reset due to error setting receive frequency is a known random issue. Some fixes have gone into release 13.4 to address this. However, if it happens every boot of the radio, it can be a hardware failure and should contact support. Charlie Galik Principle Staff Software Engineer Cambium Networks Community Forumhttp://community.cambiumnetworks.com/ From: Af [mailto:af-boun...@afmug.com] On Behalf Of Brian Sullivan Sent: Monday, July 20, 2015 11:41 AM To: af@afmug.com Subject: Re: [AFMUG] 450 SM ADI communication failure I believe this was a new-in-box unit we found during our pre-config process.� Sorry, I don't have more info on it. On 7/20/2015 11:27 AM, Ken Hohhof wrote: This is an SM that has been in service for a couple months, I am troubleshooting it remotely.� It did eventually register, otherwise I could not see the log entries.� Now I see a new one: � 07/20/2015 : 15:31:46 UTC : :XO trim at min diff=-37 c=0 cmove=-1 f=0 fmove=113 07/20/2015 : 15:31:52 UTC : :XO trim at min diff=-1389 c=0 cmove=-9 f=8064 fmove=-39 07/20/2015 : 15:31:53 UTC : :XO trim at max diff=1394 c=58 cmove=9 f=0 fmove=44 07/20/2015 : 15:31:55 UTC : :XO trim at max diff=6133 c=63 cmove=41 f=8191 fmove=-17 07/20/2015 : 15:31:56 UTC : :XO trim at max diff=7178 c=63 cmove=48 f=8191 fmove=-22 07/20/2015 : 15:31:58 UTC : :XO trim at max diff=7178 c=63 cmove=48 f=8191 fmove=-22 07/20/2015 : 15:31:59 UTC : :XO trim at max diff=7177 c=63 cmove=48 f=8191 fmove=-23 07/20/2015 : 15:32:01 UTC : :XO trim at max diff=7176 c=63 cmove=48 f=8191 fmove=-24 07/20/2015 : 15:32:19 UTC : :XO trim at max diff=5242 c=63 cmove=35 f=8191 fmove=-8 07/20/2015 : 15:32:20 UTC : :XO trim at max diff=7216 c=63 cmove=49 f=8191 fmove=-134 07/20/2015 : 15:36:43 UTC : :XO did not trim after 200 attempts. FPGA TCXO/XO compare:04c497e2 (79992802) 07/20/2015 : 15:37:55 UTC : :Reset due to error setting receive frequency 5540 at temperature 46 C 07/20/2015 : 15:38:55 UTC : :Forced reset; 07/20/2015 : 15:38:55 UTC : � I had moved the AP from 5.7 to 5.4 as a troubleshooting step, I think that is unrelated to the problem, but this looks like a problem adjusting a VCXO to the AP frequency.� Did you see something like this on yours also, or just the ADI communication failure?� (I assume that refers to communication with an Analog Devices Inc. chip). � � From: Brian Sullivanmailto:installe...@foxvalley.net Sent: Monday, July 20, 2015 11:18 AM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] 450 SM ADI communication failure � We currently have an RMA ticket open regarding this.� The note from our guys about it was, The unit I am looking at says 'ADI Communication failure' at the top of the status page. After factory resetting and configuring the unit, that error message is still there. So not familiar, but Cambium had no problem letting us RMA the unit. On 7/20/2015 11:05 AM, Ken Hohhof wrote: Anyone familiar with this log entry?� I'm assuming I have an SM with a hardware problem?� We had heat advisory Saturday but mostly due to high humidity, I don't think the actual temperature got above 90. **System Startup** System Reset Exception -- Watchdog Reset Cur ExtInt 0 Max ExtInt 0 Cur DecInt 0 Max DecInt 0 Cur Sync 0 Max Sync 0 Cur LED 1 Max LED 1 Cur WDOG 0 Max WDOG 1 Cur EthXcvr 0 Max EthXcvr 1 Cur FEC 0 Max FEC 0 Cur FPGA 0 Max FPGA 0 Cur FrmLoc 0 Max FrmLoc 0 Cur WatchDog 33 Max WatchDog 33 RTMLogStats 0 AAState 0 Software Version : CANOPY 13.2 SM-DES Board Type : P11 Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module - 0a-00-3e-b2-03-92 FPGA Version : 081514 FPGA Features : DES, Sched; 07/20/2015 : 15:09:03 UTC : :ADI communication failure 07/20/2015 : 15:09:03 UTC : :InitADI936x() : Catalina register failures, ADI forced reset has been invoked! 07/20/2015 : 15:10:03 UTC : :Forced reset; 07/20/2015 : 15:10:03 UTC : **System Startup** System Reset Exception -- Watchdog Reset Cur ExtInt 0 Max ExtInt 0 Cur DecInt 0 Max DecInt 0 Cur Sync 0 Max Sync 0 Cur LED 1 Max LED 1 Cur WDOG 0 Max WDOG 1 Cur EthXcvr 0 Max EthXcvr 1 Cur FEC 0 Max FEC 0 Cur FPGA 0 Max FPGA 0 Cur FrmLoc 0 Max FrmLoc 0 Cur WatchDog 33 Max WatchDog 33 RTMLogStats 0 AAState 0 Software Version : CANOPY 13.2 SM-DES Board Type : P11 Device Setting : 5.4/5.7GHz MIMO OFDM - Subscriber Module - 0a-00-3e-b2-03-92 FPGA Version : 081514 FPGA Features : DES, Sched; 07/20/2015 : 15:13:43 UTC : :Time Set
Re: [AFMUG] pmp100 pmp450 sync calculator issues
Hey AF, Yes, correct there are no FSK RF changes, just an accidental Frame Calculator Web Page change. I have found the bug and this will be fixed in 13.4.1. Sorry about this accidental change. For those that want more information: The AP starts actually receiving immediately before the “Max Range” time is allocated in the frame, for SMs that are at the max distance away. Even though the data from the SM’s won’t appear until later in the frame, this allows the AP to receive registration requests from SM’s that don’t know how far away they are. In 13.3/13.4 the frame calculator page was accidentally changed to show this time. In 13.4.1 it will go back to the old time and be “AP Receive Data Start”. This extra time that was included in 13.3/13.4 does not need to be sync’d, so the bigger number can be used. So use a 13.1.3 frame calculator page in the meantime. George, you were exactly right. Craig, Thanks for pointing this out. Sorry for the delay, but I wanted to find the bug before I could answer with 100% certainty. Ken, to answer your question I was in there changing code in 13.3 to be able to sync 5 ms frame with PMP 320 product. I enhanced the Frame Calculator Tool for OFDM to show what the times are for the antenna port of the radio, so more exact synchronizing could be done. There’s good parts and bad parts to having a common code base, and this is one of the bad parts. ☺ I would turn around and say where was our beta testers?!? We had a beta open for months! ☺ 13.4.1 beta anyone? ☺ Apologies again and we appreciate you guys and we appreciate your feedback. Enjoy your day, Charlie Galik Principle Staff Software Engineer Cambium Networks Community Forumhttp://community.cambiumnetworks.com/ From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof Sent: Thursday, July 16, 2015 8:49 AM To: af@afmug.com Subject: Re: [AFMUG] pmp100 pmp450 sync calculator issues Can you tell I was a HW engineer? And then a PHB*? Software was just a SMOP**. Everything is easy when someone else has to do it. And mistakes are obvious once someone has pointed them out. -- * Pointy Haired Boss ** Small Matter Of Programming From: Matt Mangriotismailto:matt.mangrio...@cambiumnetworks.com Sent: Thursday, July 16, 2015 7:01 AM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] pmp100 pmp450 sync calculator issues Oh Ken… you think this is so easy. ☺ From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof Sent: Wednesday, July 15, 2015 8:43 PM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] pmp100 pmp450 sync calculator issues Why was someone even in there changing code? And whatever happened to automated regression testing? From: George Skorupmailto:geo...@cbcast.com Sent: Wednesday, July 15, 2015 8:21 PM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] pmp100 pmp450 sync calculator issues I updated a 900 AP. Looking at /engineering.cgi on this 13.4 AP and a 13.1.3 AP, the current frame configuration matches. The frame calculator is definitely broken. I see what the difference is now. The new calculator shows max range air delay as one-way, while the previous calculator shows round-trip air delay. Somebody forgot to do math somewhere. So the new calculator needs one-way air delay added to the AP's Rx Start value. Not the end of the world, but yes, confusing. On 7/15/2015 5:04 PM, George Skorup wrote: My guess is it's just the calculator page code that got mucked up, not the actual running RF operation/framing. Go to one AP that is on 13.1.3 and another that's on 13.4. Log in and change the URL to /engineering.cgi and look at the Current Frame Configuration on both radios. They should match. If they don't then... uh oh. I don't have enough stuff updated yet to do this myself. On 7/15/2015 3:47 PM, Craig Schmaderer wrote: This case has now been sent up to upper level engineers.� I guess this might be a huge bug, no one can still tell me what calculator is the correct value or if the new software is even running the right time when you upgrade.� I would be careful upgrading radios if you need to time your 100 and 450 together until this gets resolved.�� � Craig R. Schmaderer CEO | Skywave Wireless, Inc. Ph: 402-372-1975 | Fax: 402-372-1058 Direct: 402-372-1052 � From: Af [mailto:af-boun...@afmug.com] On Behalf Of George Skorup Sent: Thursday, July 09, 2015 6:13 PM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] pmp100 pmp450 sync calculator issues � WTF. So is it the new one or the old one that's wrong? I just ran your dimensions on a 450 AP running 13.2.1. I got the same as your FSK on 13.1.3. Apparently something changed after 13.2/.1. On 7/9/2015 2:34 PM, Craig Schmaderer wrote: So I have a ticket open with cambium on this issue.� Have you guys noticed the fsk calculator on pmp100 radios with software 13.1.3 and lower give you different results than the fsk calculator on a 450 radio running 13.3? I canï
Re: [AFMUG] PTP450: new sessions several times a minute; is this a problem?
Bill, The log you send is completely normal for Canopy PTP products. This is a “Keep Alive Request Time Out” (KAREQTO) set after the backhaul slave sends a keep alive packet to the backhaul master. The backhaul master immediately responds with a Keep Alive Response (KARSP), which is logged as well. 8 seconds later the process is started over again to ensure the link is still up and well. There is no problem from the logs you reported, as the master is responding every time. The “NewState: REGISTERED” is a bit misleading, as the last state was Registered, so it didn’t really change states. To see if your session is stable, check the Session Uptime on the BHS’s home page: [cid:image001.png@01CFE8CD.7C2B5CB0] Note, by default the Backhauls generate a fresh encryption key every 24 hours. This is control on the BHM’s Configuration -- Security page: [cid:image003.png@01CFE8CD.D960E760] Ken, On the separate PMP issue, the AP setting for the “SM Receive Target Level” of -59 dBm is not too hot. I do not know of any issues setting this to a higher number, besides of course increasing your self-interference with an AP on the backside. Enjoy your day, Charlie Galik Senior Staff Software Engineer Cambium Networks From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof via Af Sent: Wednesday, October 15, 2014 2:39 PM To: af@afmug.com Subject: Re: [AFMUG] PTP450: new sessions several times a minute; is this a problem? Sorry, my eyes missed that the post was about a PTP450 not PMP450. Still, I would be interested to see if it still happens if you temporarily crank down the xmt power a bit. From: Bill Prince via Afmailto:af@afmug.com Sent: Wednesday, October 15, 2014 2:27 PM To: af@afmug.commailto:af@afmug.com Subject: Re: [AFMUG] PTP450: new sessions several times a minute; is this a problem? This is 5.8 GHz. We set the timing on the AP to match the co-located PMP450 APs that are operating nearby (both physically and on nearby channels). There is no setting on the BHM to auto-adjust power. This is what the Link Status looks like right now. Maybe the uplink is a little hotter [cid:image002.png@01CFE8CD.7C2B5CB0] bp On 10/15/2014 12:22 PM, Ken Hohhof via Af wrote: Sure sounds like a problem to me. Out of curiosity, what do you have the target signal level from SMs set to on the AP? And as an experiment, if you drop the AP xmt power something like 3-6 dB, does it have any effect on the symptom? Cambium says –59 isn’t too hot, but I wonder. Also, what frequency band? From: Bill Prince via Afmailto:af@afmug.com Sent: Wednesday, October 15, 2014 2:08 PM To: Motorola IIImailto:af@afmug.com Subject: [AFMUG] PTP450: new sessions several times a minute;is this a problem? We're getting these New Session messages quite often on a new PTP450 installation. Everything else looks real peachy. SNR varying between 32 and 35, Rcv power ~~ -59; almost equal V/H ratio, etc. Any idea what it's trying to tell me? Is this a problem? Session timer keeps getting rest on some (not all) of these events. We're running the 13.2 build 34 on link. 10/15/2014 : 11:58:15 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:15 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:23 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:23 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:31 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:31 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:39 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:39 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:47 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:47 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:55 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:58:55 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:03 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:03 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:11 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:11 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:19 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:19 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:27 PDT : Event: SMSESMSG, MsgType: KAREQTO, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:27 PDT : Event: SMSESMSG, MsgType: KARSP, NewState: REGISTERED, Flag 0 10/15/2014 : 11:59:35 PDT
