Following a scheduled update at 3am through cnmaestro to 2 450 and 2 450i 3ghz ap's and the connected sm's to 16.2.1 to get ready for CBRS. Later that morning we found at least 5 idle sessions on 3 ap's and 15 on the last. and the calls started... What I found at the first 2 customers was plug in and power cycle, sm boots up and begins CBRS spectrum analysis. It never actually starts so it never finishes and starts normal operation. The SM session status just shows aiming and nothing changes, the SM sits there for hours doing nothing.
I found that overriding the SM and selecting all frequencies and reboot seemed to get it going. a couple others were more difficult and I had to set to factory defaults and reprogram. This was an instant 30+ service calls over the last 3 days because some dropped off later.
To my knowledge this did not affect 450b SM's. The AP's updated had CBRS disabled, We have 1 450m AP and connected SM's running 16.2.1 and CBRS and have not observed this issue.
I have rolled back the SM's to 16.1 on these AP's because we cannot continue having this issue and truck rolls for it.
CBRS has been a continual problem for us since it has come online. The issue is after the SM boots up it hangs before starting the spectrum analyzer so it never starts transmitting and comes into session and it will sit there until it is told to stop spectrum analysis or the SM is rebooted multiple times.
Issue started in 16.2.1 and is still happening in 21.0
These pictures are from a neighborhood that had a power bump, out of 19 SM’s affected 4 did not come back online, I plugged in and stopped spectrum analysis on a SM and it connected.
That is just this morning, This is a daily/weekly issue.
There are open tickets on the topic already that have been open a long time.
@RCW-Andrew, sorry for the no response from Cambium on this issue. I was unaware that this was still a problem. I’m not a CBRS expert, but I can try to look into this for you. Would you email me a few eng.cgi from SMs running 21.0 that had this issue?
This on going issue we experience is perceived as outages from customers when the SM’s just sit and wait, Because of this…
•We have lost customers/revenue
•We have been verbally assaulted by angry/frustrated customers which in turn affects staff mental/emotional health.
•Customers have a bad experience with us which hurts our reputation in an age of remote workers and competing with a government funded fiber company or Starlink.
•We have stopped opening tickets over this because they go unanswered and unresolved.
Please guys we need help to get this resolved. It is hard to believe that we are the only company using the pmp450 3.6 after CBRS facing this issue.
Look in the event log, what does it say is causing the reboot?
If this is CBRS related, you can go on the AP and look under Logs → CBRS Logs, and then select the SM having issues, and press save, and then it will display all the CBRS related events that have occured with that SM.
Are you within a couple hundred miles of the coast?
Hello Eric I believe we have spoke about this before.
I mean as sitting and waiting is the SM says in red after boot up Spectrum Analysis in progress. But it does not do it, It sits there and never scans so it never stops trying to scan and never transmits and establishes a session and it will do is indefinitely. An early post of mine on this thread shows the companies 3ghz CPI personal connection sat for almost 14 days “scanning spectrum” with no results.
Event log shows nothing abnormal. The cause of the power cycle can be a manual reboot, it can be power bump, a firmware update, even a new installation which a newer tech fought with just this morning, I had to drive out and turn off the spectrum analysis scan it was currently up to 18 minutes when I arrived.
It does not seem to be a CBRS issue at the AP because the SM has to scan spectrum and then stop, And that has always been the problem. We first seen this issue on 16.2.1 before we enabled CBRS. Once the SM was coded to scan spectrum at boot it became a problem.
We are over 500 miles from the coast in southeast Utah.
We have opened many tickets with Cambium submitting screenshots and engineering files, we have stopped opening tickets over this because they go unanswered and unresolved. The last few tickets we had about this were months old and were eventually closed by Cambium support with no explanation.
Due to how CBRS works, you do not want your radios scanning at a 2.5MHz raster. SAS allocations are based on 10MHz grants, so a 5MHz raster is more efficient and faster. Furthermore, if the SAS needs to change your frequency and/or channel width, you should have the 10/20/30/40MHz selections in place (if you have no plans on using 30, or 40… then at least have 10 and 20 selected). Lastly, the rule is… for 40MHz and 20MHz channel widths, always choose channel ending in 0. For 30MHz and 10MHz always choose a channel ending in 5. This is due to the 10MHz block allocations granted by the SAS. For example, you do not want to have a 20MHz carrier at 3605, because it will request 3x 10MHz grants when only 2x 10MHz grants are needed.
We have over 1300 PMP450 CBSD’s and they all run perfectly fine. I’d highly suggest that you take a chance on the good known working (and recommended by Cambium) settings I’m using to see if that resolves your issues.
