Another request to show both chains

Lost of users have been asking for this for years and I couldn’t imagine it involves a massive amount of coding. At present, we have to choose an SSID, allow the station to connect and only then can we see the chains. When you’re upgrading or installing a new AP on a tower with dozens of end users, this is extremely time consuming and frustrating. Installers also don’t appreciate having to go through this procedure (often on a rooftop or pole) when there are 2 or 3 access points with a similar overall RSSI.

I’d also request this be displayed on the access point under Monitor->Wireless, the main station summary page and ideally on CNMaestro.

1 Like

Hello @scracha ,

thank you for your request!
Could you tell me more details on your use scenario?
Would you like to see something like in eAlign per chain RSSI in SMs scan list of APs?

@aka Somewhat related but I would really love to have the SM show both the SM RSSI and the AP RSSI on either the Status page of the SM or the Monitor->Wireless page.

I am used to other wireless brands that have this and it makes it very useful when aiming and especially helpful for the 6ghz products that have weaker signals in the AP direction due to AFC limits.

Right now, I have to login to the AP remotely and check the AP side wireless page to see the SM upload signals.

2 Likes

Hi @aka

We love the ePMP radios’ performance but sometimes the GUI drives us crazy.

Scenario 1: Installer goes to customer. Points station radio at tower (sometimes multiple towers). Current scan only gives RSSI and SSID so installer has no idea about chains on chosen or other APs. Installer connects to AP with best RSSI. Installer may be unaware that chosen AP may have larger chain mismatch compared to other AP with a weaker overall RSSI. This can happen if station is near the “edge” of a sector (azimuth or elevation) or if the AP with the weaker overall RSSI but better chains is on a lower powered DFS channel or simply has the TX turned down, as is often the case if we install an AP with a lot of downtilt for “close” customers.

Scenario 2. When new APs are added (or upgraded from say, ePMP3000L to ePMP3000 or ePMP4000) at a tower, network engineer logs in remotely to each station and essentially has the same issue the original installer has WRT not knowing if both chains are OK before connecting an end remote radio to the new AP.

Scenario 3. When APs are “busy” and network engineer is trying to balance out stations. They may want to choose a less busy AP with a slightly weaker RSSI (e.g. -62dBm instead of say, -57dBm on the “busy” AP). The connect station to less busy AP only to find one of the chains is 10dBm weaker than the other. They then have to reconnect station back to other AP. By the time they’ve repeated this process with a dozen of the 40 stations they’re looking to migrate, Network engineer occasionally wishes they were working on one of their access points that are made in China or Latvia :slight_smile:

Scenario 4: AP or station(s) rotates a few degrees in high wind. This can frequently result in just one chain degrading significantly but the overall RSSI barely drops. Currently we have no way of knowing this without logging into each station.

Scenario 5: One chain fails or lead fails on connectorised AP or station. 2 or 3 dBm drop may not be noticed, especially as CNMaestro on-premises has a 7 day historical limit :face_exhaling:. Currently we have no way of knowing this without logging into each station.

Scenario 6: Tree, other plant growth or building (!!) gets in the way of station. This often just affects the horizontal chain. Currently we have no way of knowing this without logging into each station.

On the ePMP station interface:

  • When running eAlign, both chains should be shown on ALL the scanned SSIDs / APs
  • The chains should clearly be shown on the station’s main status screen.

On the ePMP access point interface:-

  • Monitor->Wireless should show the chains in the RSSI uplink/downlink column

On CNMaestro:

  • Both chains should be shown in list view at Monitor->Networks->Default/Tower/AP->Statistics
  • There could also be a column with “chain difference” that can be ordered ascending/descending.
  • It would be fantastic if CNMaestro could display the OTHER APs RSSI and chains that the ePMP stations have scanned. Even if it this were done via some sort of scheduled overnight scan it would help track down issues with interference and stations currently connected to a less than optimal AP..

Vehicle manufacturers gain inspiration from each other. If Cambium aren’t looking at their main rival’s NMS (the free one written > 10 years ago is quite frankly superb) and radio HTML interfaces then they’ve got rocks in their head.

6 Likes

The GUI is one of the most frustrating things to use… Going back and forth between 3,4, 5 different locations constantly and trying to contrast and compare information from memory drives us mad. I know this is much broader than the initial request, but a LOT of the information really should be available and displayed on single screens.

2 Likes

YES - this is exactly what I’ve been saying for years. A 'single plane of glass" with all the pertinent info on it. And ASK WISPs WHAT WE NEED in the field. Consult with us in an open brainstorming session, listen to our feedback. AND/OR, look at the info presented on everyone’s else’s GUI.

Thanks for raising this — your feedback is helpful, and we really appreciate the thoughtful detail.

Right now, during scanning, the SM receives broadcast frames (GPFs) from nearby APs. The chipset processes these using both chains together and reports a single combined RSSI. It doesn’t break out per-chain values at this stage because there’s no MIMO training yet — and without that exchange, the chipset can’t separate or measure individual chain strength.

This isn’t a software limit so much as a chipset-level behavior. Most Wi-Fi-derived platforms are optimized for fast scanning and don’t expose chain-level metrics until after association.

We know how valuable this would be in the field, and we’ll continue exploring options to improve the installer experience. In the meantime, one workaround could be to use eAlign on multiple candidate APs, since it provides per-chain RSSI once connected. While that requires connecting to each AP individually, it may help avoid committing to an AP with unbalanced chains before final alignment.

I’ve already began discussions with an ePMP Core Team member as to whether there’s a smarter way we can support this workflow without the extra effort.

3 Likes