PMP450x Release 20.2.1 is now available

Cambium is officially releasing the PMP450x Radio 20.2.1 software.
Radio software and documentation can be found at and CBRS procedures that involved both cnMaestro and radio software can be found in the cnMaestro repository at

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.

Thanks for the reminder, @George_Skorup. I’m following up that this gets posted on cnArcher.

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. :slight_smile: 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
then click here
Download the QQ radio code and submit that PDF with a support ticket.

1 Like

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.

1 Like


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?