Regarding the new EVM feature, on Tools->Link Status I see Average EVM (dB) for Uplink Statistics populated with values. The Average EVM for Downlink Statistics shows as NA. This is on a 450M. Is this maybe a display issue?
Chrome worked fine for me (no extensions). Firefox needed ublock disabled in order to display the heat map.
@rnelson wrote:Regarding the new EVM feature, on Tools->Link Status I see Average EVM (dB) for Uplink Statistics populated with values. The Average EVM for Downlink Statistics shows as NA. This is on a 450M. Is this maybe a display issue?
As you might already know, this feature is new to 16.1.
Please upgrade your SM to 16.1 and let me know if you still have any issues.
anyone getting a bunch of stuck sessions on the AP's after the upgrade to 16.1?
| System Reset Exception -- Power-On Reset |
| Software Version : CANOPY 16.1 AP |
| Software Boot Version : CANOPYBOOT 1.0 |
| Board Type : P14 |
| Board Temperature : 0 C / 32 F |
| Device Setting : 3.6GHz MU-MIMO OFDM - Access Point - 0a-00-3e-60-73-01 |
| No valid accounts configured. Using default user account - 3660.000 MHz - 20.0 MHz - 1/16 - CC 246 - 5.0 ms - Other Regulatory/Other |
| FPGA Version : 0a0a76; |
| 08/21/2019 : 12:24:28 UTC : :Time Set |
| 08/21/2019 : 12:24:49 UTC : Acquired sync pulse from Main/Power Port |
| 08/21/2019 : 14:17:49 UTC : :Stuck Session: Data (LUID 63) (1) |
| 08/21/2019 : 14:22:56 UTC : :Stuck Session: Data (LUID 57) (1) |
| 08/21/2019 : 14:22:59 UTC : :Stuck Session: Data (LUID 84) (1) |
| 08/21/2019 : 14:23:03 UTC : :Stuck Session: Data (LUID 79) (1) |
| 08/21/2019 : 14:23:08 UTC : :Stuck Session: Data (LUID 82) (1) |
| 08/21/2019 : 14:23:11 UTC : :Stuck Session: Data (LUID 81) (1) |
| 08/21/2019 : 14:23:22 UTC : :Stuck Session: Data (LUID 78) (1) |
| 08/21/2019 : 14:23:24 UTC : :Stuck Session: Data (LUID 54) (1) |
| 08/21/2019 : 14:23:25 UTC : :Stuck Session: Data (LUID 69) (1) |
| 08/21/2019 : 14:23:26 UTC : :Stuck Session: Data (LUID 77) (1) |
| 08/21/2019 : 14:23:30 UTC : :Stuck Session: Data (LUID 66) (1) |
| 08/21/2019 : 14:23:33 UTC : :Stuck Session: Data (LUID 64) (1) |
| 08/21/2019 : 14:23:42 UTC : :Stuck Session: Data (LUID 67) (1) |
| 08/21/2019 : 14:24:04 UTC : :Stuck Session: Data (LUID 65) (1) |
| 08/21/2019 : 14:24:38 UTC : :Stuck Session: Data (LUID 71) (1) |
| 08/21/2019 : 14:25:09 UTC : :Stuck Session: Data (LUID 80) (1) |
| 08/21/2019 : 14:25:14 UTC : :Stuck Session: Data (LUID 52) (1) |
| 08/21/2019 : 14:25:50 UTC : :Stuck Session: Data (LUID 88) (1) |
| 08/21/2019 : 14:25:51 UTC : :Stuck Session: Data (LUID 3) (1) |
| 08/21/2019 : 14:25:56 UTC : :Stuck Session: Data (LUID 59) (1) |
| 08/21/2019 : 14:26:05 UTC : :Stuck Session: Data (LUID 58) (1) |
| 08/21/2019 : 14:26:34 UTC : :Stuck Session: Data (LUID 51) (1) |
| 08/21/2019 : 14:26:49 UTC : :Stuck Session: Data (LUID 85) (1) |
| 08/21/2019 : 14:27:50 UTC : :Stuck Session: Data (LUID 50) (1) |
| 08/21/2019 : 14:28:26 UTC : :Stuck Session: Data (LUID 86) (1) |
| 08/21/2019 : 14:28:45 UTC : :Stuck Session: Data (LUID 48) (1) |
| 08/21/2019 : 14:28:51 UTC : :Stuck Session: Data (LUID 60) (1) |
| 08/21/2019 : 14:29:11 UTC : :Stuck Session: Data (LUID 73) (1) |
| 08/21/2019 : 14:29:42 UTC : :Stuck Session: Data (LUID 49) (1) |
| 08/21/2019 : 14:30:07 UTC : :Stuck Session: Data (LUID 87) (1) |
| 08/21/2019 : 14:30:33 UTC : :Stuck Session: Data (LUID 2) (1) |
| 08/21/2019 : 14:30:37 UTC : :Stuck Session: Data (LUID 75) (1) |
| 08/21/2019 : 14:31:31 UTC : :Stuck Session: Data (LUID 74) (1) |
| 08/21/2019 : 14:32:51 UTC : :Stuck Session: Data (LUID 56) (1) |
| 08/21/2019 : 14:33:13 UTC : :Stuck Session: Data (LUID 89) (1) |
| 08/21/2019 : 14:33:49 UTC : :Stuck Session: Data (LUID 76) (1) |
| 08/21/2019 : 14:34:34 UTC : :Stuck Session: Data (LUID 72) (1) |
| 08/21/2019 : 14:34:43 UTC : :Stuck Session: Data (LUID 53) (1) |
| 08/21/2019 : 14:36:51 UTC : :Stuck Session: Data (LUID 70) (1) |
| 08/21/2019 : 14:36:52 UTC : :Stuck Session: Data (LUID 83) (1) |
| 08/21/2019 : 14:39:02 UTC : :Stuck Session: Data (LUID 68) (1) |
| 08/21/2019 : 14:39:23 UTC : :Stuck Session: Data (LUID 55) (1) |
| 08/21/2019 : 14:39:44 UTC : :Stuck Session: Data (LUID 61) (1) |
| 08/21/2019 : 14:40:02 UTC : :Stuck Session: Data (LUID 62) (1) |
Hi jaggermifter,
Could you please email me the field_diags from AP.
My email id is balaji.grandhi@cambiumnetworks.com.
Thanks,
Balaji
Hi Balaji
Sorry for the late reply. I managed to fix it. It only happens when the Proportional Scheduler was in use with no encryption. since AES has been enabled the issue stopped.
Thanks
Brenton Kidd
@jaggermifter wrote:Hi Balaji
Sorry for the late reply. I managed to fix it. It only happens when the Proportional Scheduler was in use with no encryption. since AES has been enabled the issue stopped.Thanks
Brenton Kidd
Thanks for the info, Brenton. We will investigate it.
Hi guys
is it safe to upgrage to 16.1 both AP and CPEs?
I've had good luck running everything at 16.1 as far as upgrading, but we've run into a problem where some SM's aren't seeing the AP when initially setting them up This might be an issue with cnArcher though, we're still looking into it. downgrading to 16.0.1 on the SM solved it for us
2 Likes
We have had an odd thing cropping up with 16.1 on one of our loaded APs. It's like layer 3, ip traffic is stopping, but the layer 2 protocol the AP communicates to the SM with still works. It has happened twice now, an SM will come up as down in our IP polling software, but I can still access via the AP. The provider cannot reach the radio via IP. Dropping the session or rebooting the SM does not seem to fix it. When I rebooted the AP, all 94 customers came back, but not all the radios could be reached via IP.
I've let Cambium know, but wondering if anyone else is experiencing this.
Any news on the 2 above issues, or the next release plan?
@CSup wrote:Any news on the 2 above issues, or the next release plan?
CSup,
I'm not aware of any progress on the 450m Stuck Session nor the IP layer issue reported on this thread.
We are presently working on a 16.1.1 which is follow up bug fix release and support for the new 450b 3 GHz High Gain and MicroPoP 5 GHz APs. Some fixes include:
- CPY-16024 and CPY-16129 - PLL Lock Lost and a SM unable to register after upgrade to 16.1
- CPY-16071 - Add Web banner text to SNMP
- CPY-16009 - 450m Encryption is reset from "AES" to "None", after upgrading to 16.1
- CPY-15951 - Fix SM unable to register due to "Used VC database overflow"
- Other minor bug fixes
We are aiming to have an open beta build next week and I would appreciate you trying it out when it is available.
Charlie
Hi, is it confirmed that there will be the released a new Beta for the PMP 450 this weekend? :)
@Tuvix_IT wrote:Hi, is it confirmed that there will be the released a new Beta for the PMP 450 this weekend? :)
I appreciate your enthusiasm and follow up. :) We've decided to hold off to wait for a fix where after a LBT event the SM is unable to register to the AP unless the Idle Sessions are cleared.
So I confirm there will not be released a new beta for 450 this weekend. We'd rather wait a bit then have 16.1.1 (BETA-1) followed in a few days by 16.1.1 (BETA-2).
Charlie
1 Like
@jaggermifter wrote:Hi Balaji
Sorry for the late reply. I managed to fix it. It only happens when the Proportional Scheduler was in use with no encryption. since AES has been enabled the issue stopped.Thanks
Brenton Kidd
To follow up on this issue, we have root caused and fixed the issue with Proportional Scheduler on the 450m in 16.1.1 (Build BETA-3). Thanks for reporting this issue.
Happy Holidays to you and your networks,
Charlie
In Configuration > General, the Sync Setting for Remote Device Type doesn't not save PMP 100 after a reboot.
It reverts back to "Other".
Hey FVI,
I tested this on my own setup and can also see the problem. We will try to get this fix into 16.1.1.
Regards,
Steven