I do understand that Cambium has tried to filter that list to just show the on-channel interferers, and to eliminate the unnecessary display of all the low signal and way off channel systems which are not considered a concern. However, a 'more details' or 'show all' type of option would be very handy - so that it can show info such as.
- Channel - Channel width - MAC lookup and show manufacturer - Indication if it's a "WiFI" or "Airmax" or "ePMP" or whatever 'flavor'
On a 'long/complete' list of all visible systems, it would be good to have that list sortable by signal strength - if we are looking to change channels, it would be good to know BEFORE we change channels if there is likely going to be an interferrer on the new channel. Right now, we basically can't see anything on the new channel until we switch to that new channel, and only then will eDetect tell us about the interferers on the new channel.
Also - even on the existing eDetect list - it should show the frequency of the interferer. I know it says ''on channel interferer'' but if it shows the client's router ''dlink at -52'' and we tell the client that they should reconfigure their router - it's very handy to be able to specifically tell them ''your router is on 2452 right now, you should change it to 2412''
I love this idea, Even if "advanced dectect" needed to disconnect, scan collect information on other channels, ect then comback in a couple minutes, that feed back in a few minutes would be golden.
It would be nice if there was a way for eDetect to find interferers that are not on the exact same channel as the ePMP SM, but are still causing interference - for example, we might have the ePMP on 5.745ghz, and the customer's router is on 5.765ghz, but eDetect will never see it, or even if the ePMP is on something like 5.77ghz. This is especially becoming more of a problem with a lot of the new AC routers defaulting to 80mhz wide channels.
Other comments/suggestions/discussions I've seen about this: byGuilherme
02-06-201702:45 PM- edited 02-06-201702:55 PM
This mode would be incompatible with the way eDetect works today. (listen during unused TDD-Tx frames)
To look into adjacent channels, the tool would have to drop all connections, and switch/listen to the multiple center frequencies close to the one being used.
I see some value in adding this feature (being able to see the SSID of the interferers helps a long way in finding out where it's coming from, etc), but since the radio would have to drop the connections, you might aswell run the ACS tool, and take a look in all the spectrum.
But the combination of the option to look in adjacent frequencies "Site Survey" style, and being able to run ACS without having to ""enable / run / revert the automatically populated frequencies / disable"" would be very welcome.
About the 80mhz channels, there is a worst case scenario where you have a lower interferer in "Ceee" mode, and an upper interferer in "eeeC" mode.
Since the beacon of the 80mhz AC frame is transmitted only in the control-channel, but you are actually being interfered by the extension ones, you have to scan a pretty wide chunk of spectrum to be able to find those interferers (something like -90 to +90 Mhz from the desired center).
Yes, I know it wouldn't work the way eDetect currently works, but I don't see dropping the connection as a problem, since this would primarily be needed on the SM. How I would see it working, would be to drop the connection, run a full scan for 802.11 APs, and then re-establish the link and display the results of the scan.
ACS doesn't really help, in the situations I'm talking about, since that's only going to be happening on the AP... what I want is a way to scan on the SM for nearby routers that are interfering, which the AP can't even see in a lot of cases.
Yes - good suggestions all. :) Basicaly, what we run into is that a customer that has been working fine for a while and who suddenly has problems calls - and we basically have our hands tied trying to figure out what his problem's are.
A) We can't run a Spectrum Analyzer from his side without driving there, and B) We can't run an eDetect that will show us much useful information, unless the interferer happens to be on the same channel & width as the client SM is.
In most cases, the offending interferer is something new that the client has added to their network - so it's a new router, or they've reset their router to factory defaults (which is often 'Turbo' or 80Mhz wide), or it's a new ChromeCast or Wireless Security or Baby Monitor (all often WiFi) and without being able to see these things in either Spectrum or ''Sight Survey'' we pretty much need to drive to their place in order to diagnose it. That means it's a van and half a day for an installer, instead of 10 minutes by a phone support guy.
PLUS - when you do find that its the new router that they've added to their network, that really becomes BILLABLE time if we go to their place to help them learn about RF things that they've addd to their network. So if we only discover that once we are at their place, that often equals a fight to get paid or an unhappy customer. Whereas if we can tell a client over the phone ''OK, I'm pretty sure it's your router on 2467 @ -37 signal'' - we can then have the discussion righ then over the phone about ''would you like to try to resolve this yourself? Or would you like us to drive out and help teach you how program the router you bought from Best Buy for a charge?''
The way I see this working is changes to BOTH the Spectrum Analyzer as well as the eDetect (or via the addition of a ''Site Survey'' option.
A) For the Spectrum Analyzer, it needs to be available remotely. That would likely need to be a 'Timed Spectrum Analyzer' where it disconnects from the AP and scans for 5 minutes and then reconnects to display the results. ALSO, it would be essential to scan only in the normal AP RX part of the frame (the normal SM TX part of the frame.) - otherwise it's pretty much useless still. If the SM hears our AP at -59, and if the Spectrum does just a continuous scan, we'll still have no idea if the performance issues are related to 'new/external' noise because the SA will show a -59 across the current channel widths.
B) The SA should work like the WiSpy device does. It would be good for Cambium to buy some WiSpy devices and use them and see how they work. They have a mode for example where it shows a combination of the SA progress, and also can overlay the WiFi Router/AP information it knows about. So, it can show a peak in signal, but also overlay that there is a 'Linksys' ESSID at that same location. That's VERY useful to detecting a quiet AP. It does no good to scan and think that 2412 is quiet(ish) but it's only quiet because the kids aren't using the internet at that moment. Overlaying the ESSID information on the SA results is easier to show what and where each device is.
C) For the actual eDetect, it needs to be able to show ALL WiFi and UBNT and Cambium and MikroTik and anything else that it can be programmed to find. Again, if that has to disconnect for 5 minutes and do it's thing and then re-connect afterwards, thats WAY better and WAY less disruptive than having to drive out to run it at the client's site. And WAY less disruptive than having to change the AP from 10 Mhz to 20 Mhz and disruptiing
D) It would then be good to be able to sort those stations that eDetect (or Site Survey) shows via Signal Strenght (we don't care too much about the -92) and also sort via channel proximity (we don't care too much about someone 80Mhz away). BUT, it's imporant to see them all, since that guy 80 Mhz away might be were we are planning on switching the AP to - so it's essential to know what WILL interfer if we switch to 5745, not just what is intefering now.
Cambium needs to implement the above suggestions for eDetect as well as needs to implement the remote Spectrum Analysis suggestions to allow us to remotely look at interence from the AP side - like has been the case for many years on the PMP-100 and PMP-450 radios.
The above is severely needed for us operating multiple Cambium systems out here in the field.
Add ssid display and add device names to the list. Having just the mac addresses when the device names should be known, I mean come on it is in the beacon packets and response headers that you use to get the interferers mac address from. Just add a new column so that we may have a hint of whats out there. More information is always better, just make it so we can set filters for things we dont need to know.