Cambium is officially releasing the PMP450x Radio 20.2.1 software.
Radio software and documentation can be found at https://support.cambiumnetworks.com/files/pmp450/ and CBRS procedures that involved both cnMaestro and radio software can be found in the cnMaestro repository at https://support.cambiumnetworks.com/files/cnmaestro/.
Problems and Limitations corrected in System Release 20.2.1:
Will this be on the cnArcher manifest soon?
Anyone have tried this version?
We were looking at a 20.1 upgrade but since this is final i guess we will got o 20.2.1 since it has some bug fixes even though we donāt have CBRS.
Cambium question, if we donāt have CBRS (but we do have standard 3.5ghz radios and 5ghz radios) the CBRS parameters etc wonāt affect us in any way correct? Just want to make sure before we do our first test upgrades.
Yep, was running RC4 on many radios before hand, and rolled out the release version the other night to about 2000 radios (PtPās, PMP450, 450i, 450m, 900, 2.4, 3GHz/CBRS, 5ghz). Working very well.
If youāre not using CBRS, it will not make any changes to your 3GHz radios.
We have pushed this to 1 sector using CBRS today and no problems yet, Our ābiggestā issue of many with 3.6 now is making any changes with an AP or SM that causes a session to drop may cause the SM to never link back up. We have SMās falling into a spectrum analyzer loop and they never stop unless they are power cycled 1+ times or it is manually turned off.
After the update all SMās returned which for the last several months has not been the case. A couple took 3-5 minutes longer to connect but they all did. One step forward.
6 CBRS sectors updated last night and 10 SMās stayed offlineā¦ One step back.
Sorry to hear this. Please open up a support ticket so they can gather all the information there.
Also, for those that have access by the FCC for Special Temporary Authority (STA) frequencies up to 5895 MHz, 20.2.1 STA-1 has been posted to the same private link sent to you as in the past.
@Charlie thank you very much sir! Could you also PM me the link for the STA folder so I can request access?
I loaded 20.2.1 official on a couple CBRS sectors early Saturday morning and had zero issues. SMs first and then APs. All came right back up. Granted this is a small test case, but we saw very few, if any issues on beta3 and beta4 too. Weāre planning on a mass update tonight. Still have some sectors on 16.2.x and 16.3.x unfortunately. The intermediate mod modes are definitely helping in many cases.
We currently have 1 open ticket on the issue, opened Dec 16. Last response on that was Feb 17th. it has been an issue for us since we updated the first batch to 16.2.1 on July 30 2020, We have 2 open tickets that have not been responded to in months.
We typically update from cnmaestro cloud and always do smās first, sometimes I may use cnut depending on the situation. oddly this seems to only happen to us since I have not found any other users complain about it. ĀÆ_(ć)_/ĀÆ
You have to open a support ticket with proof of your STA to get access to the link.
If you watch the APās SM registrations failures logā¦ does it show any errors (like CBRS authentication or out of range errors) for the MAC address of the SMās in question?
Unfortunately not as itās above my pay grade. 
I believe the correct procedure is to open a customer support ticket and in there upload your FCC grant-letter-thingy that shows you have been granted access to this spectrum and to have a āpaper trailā. Once given access we reuse the same link for other versions.
What he said.
To get the Authorization to transmit
Go here Login
FCC ULS
then click here
Download the QQ radio code and submit that PDF with a support ticket.
Sorry, Iām an idiot and canāt read. We do have access, but the guy that does is on vacation and I was trying not to bug him. Iāll worry about it later.
Eric,
The issue that occurs is, Lets say the customer requests a speed change, I drop the sm session so it will re-authenticate with radius/visp and update package. but it never comes back in session and no check in with ap, the most common log error we see for idle session is cbrs fail, session downtime can show 12 hours offline and when we plug a laptop in the sm it shows red letters spectrum analyzer in progress and in tools>spectrum analyzer: cbrs spectrum analysis, if we manually stop it the sm comes into session. However this only happens to pre existing connections, not new installs and never on my desk.
Def have not seen that beforeā¦ but then again, we donāt use RADIUS/visp. Iām curious, if you donāt ever drop/kick the SMā¦ does it stay registered? Iām a little confused because I thought that you said you had like 10 SMās that donāt come back after being updated to R20.2.1. I assume that youāre updating the SMās first, and then the AP?
