eDetect questions

I'm curious about the results in the image below.

Screenshot.eDetect-sector.png

Two customers on the sector currently having intermittent troubles.  Results of eDetect match up, with two units whose MACs end in :2B and :D3 being them.  (:E1 is affected too, but only gets used a few minutes a day on average)

How can the SM see an interfering signal at 29dB STRONGER than its AP, and still function at all, let alone MCS-12??  Is it not usually seeing anything from the wifi router except beacons or something?

While the unit is at MCS12 when screenshot was taken, it does fluctuate constantly - but rarely below MCS-9, at least in the 'Monitor->Wireless' view.

The 'fix' is in progress as I type, we're reaching out to those two customers and advising them that their own router is interfering, and that getting it on channel 6 or 11 will fix their problems.  (and their neighbors!) (already confirmed that 'belkin.e9e' is owned by customer at :2B, am confident that 'belkin.3fd' and other MACs with that SSID [two Nintendo MACs come up sometimes with that name] are located at :D3 customer's premises)

Separately, I wanted to suggest that it would be really useful if we got names along with 'Device MAC'.

Finally, wanted to ask what meaning the MCS holds for the AP itself, last in the list in this screenshot?  Is that just a transient snapshot of what uplink MCS was in play at the moment it updated, for whatever SM was transmitting at that moment?

j

Separately, I wanted to suggest that it would be really useful if we got names along with 'Device MAC'.


Yes - and it would also be really useful to see:

A) the actual channels these are on - so we can tell a client ''your router is on channel 4 - you should move it to channel 11 please'

B) a 'long scan' with everything it hears. I know this is supposed to be shortened to just show interferers and that is often a better and more concise list, but if we're going to change from Channel 4 to Channel 9 to see if that is better for Customer#7, it would be good to know if that's going to be worse for Customer#13 BEFORE we change channels. The way eDetect is now - we basically need to change channels, and only THEN can we to a test to see if that channel is occupied for some customer.

eDetect only shows 802.11x interfereres on the same channel and channel width as what your AP is operating on. That's why it's non-invasive and can be run without taking down currently operating SM's.


@newkirk wrote:

Two customers on the sector currently having intermittent troubles.  Results of eDetect match up, with two units whose MACs end in :2B and :D3 being them.  (:E1 is affected too, but only gets used a few minutes a day on average)

How can the SM see an interfering signal at 29dB STRONGER than its AP, and still function at all, let alone MCS-12??  Is it not usually seeing anything from the wifi router except beacons or something?


I think the reason you can see that level of noise and still operate, albiet with intermittent issues, is due to the nature of house hold WiFi devices using the CSMA MAC interfering with ePMP's TDMA MAC. If a customer's WiFi router is operating on the same channel as what their ePMP SM is operating, the SM is going to see random high-level bursts of energy from the WiFi router. When the customer starts using their WiFi to stream Netflix, this is going to create huge problems for the customer's WiFi router and moderate issues for the SM. The customer's WiFi router is going to try over and over and over again, randomly via CSMA to re-transmit the data, but it's going to keep hearing the energy from the SM... and then back off, and try again. This will create huge amounts of latency for the WiFi in the house. ePMP's TDMA is far better suited to dealing with WiFi interference and has various interference mitigation tools baked into the MAC, so it's able to keep chugging along, although there may be some additional latency and reduced throughput.


@Eric Ozrelic wrote:

eDetect only shows 802.11x interfereres on the same channel and channel width as what your AP is operating on. That's why it's non-invasive and can be run without taking down currently operating SM's.


Hi.  Yes - and eDetect it's great at what it does.  Typically, all we're interested in is a list of anything that is interfering - and I typically don't care about something 50 mhz away, or something that is a -92.  So, for most situations, eDetect is great at showing on-channel and loud things, and telling how much of a problem (or not) that thing is.

However, virtually every make/model of wireless CPE / SM out there has the ability to do a 'site survey' to show every WiFi unit it hears. Again - I'm not talking about replacing eDetect, but rather augmenting it with a new 'long site-survey' type display.

Even if the customer's CPE had to go offline for some reason, grab a scan, and then re-link to display the resuts. That'd be less disruptive than us changing the channel on the AP (all stations unlink) and then after everyone registeres again, then doing another eDetect only to find that the customer has more interferers on the new channel we've picked. It would be great to be able to ask the SM's to do a long/detailed scan - with a frequency readout  of everything it hears.

For example, this is what I see on a plain vanilia WiFi CPE...

┌──────────── Site Survey for wpci1 ──────────┐
│Freq SSID Mac Sig Sec Mode Chains WMM SGI RX-STBC AMPD
│2412 SECTOR11 d1:1a -89 OFF LEG Yes
│2417 <ssid not advertised> 03:72 -71 OFF HT20 2/130M Yes 1-stream 65K
│2427 SECTOR22 d1:25 -87 OFF HT20 2/130M Yes 40 1-stream 65K
│2442 <ssid not advertised> b7:2e -59 OFF HT20 2/130M Yes 1-stream 65K
│2442 OTHERGUY-9 1c:3a -73 WEP LEG No
│2442 SECTOR-SOUTH b7:2e -60 OFF HT20 2/130M Yes 1-stream 65K
│2452 country connection 89:48 -48 RSN HT40- 2/300M Yes 20/40 65K
│2462 <ssid not advertised> a2:3f -89 OFF LEG Yes
│2462 SECTOR-NORTH af:7b -85 OFF HT20 2/130M Yes 1-stream 65K

So - I know (before I try changing the AP to 2452 to see if that's better for her) that this customer already hears a router called 'country connection' at a -48 on that frequency.  That's unlikely to work very well and I know that before experimenting and kicking everyone offline.

Also - if we call her - I can say "OK - you have a router called 'country connection' - and it's on channel 9 and that's a problem. You should change your router to channel 1 and your internet performance will probably improve''

ePMP's tools to try to diagnose client side interference seem limited, unless I'm not understanding the magic?

eDetect only shows devices on the same channel width, so when we are operating in 10 Mhz wide 2.4Ghz channels, the client SM's say there are 'no interferers', even if the client's router is loud and proud and sitting right there blasting away.  That doesn't allow us to help diagnose a problem.

Also of course, without the ability to run a timed Spectrum from the cleint's SM either, we really have our hands tied trying to predict or diagnose interference at a client's site.

Even if we are in the same channel widths (20 Mhz wide) and even if eDetect does then show us devices that it can hear - it doesn't tell us the channels those devices are on.  It does it's own calculation to figure out if it's currently an interferer or not, but that doesn't tell us what channel it is on now.  SO - if we are planning on changing channels, we won't know until after we change channels if that will help or hinder a clients. If we could look at the eDetect list and tell what channels the other potential interferers were on, then we could make an educated channel move, not a random move and not just detect after we change, and only then know if it was a good or bad idea.

I think this is the single biggest thing we find missing from ePMP currently. We feel like we are flying blindly when trying to find the best channel - no Spectrum from the client side, no ability to tell what else is online from the client side. :(

I know it's listed as ''under consideration'' in the Ideas - but maybe it needs a few more Kudos?  :)

http://community.cambiumnetworks.com/t5/Your-Ideas/eDetect-ePMP/idi-p/51267

Just rebumping this thread, maybe someone from Cambium can comment on how we're supposed to track down performance & connection problems?

For mostly all of the people we've moved over to Cambium, it's just great.  It's way faster, way more consistent, way more reliable than our older (non-Cambium) gear and usually much better in the face of noise in most places. However, not for everyone...   we have one AP in particular which the clients disconnect or drop lots of pings and yet the old and new sectors were mounted on the same tower, identical pointing, signals on the CPE side of things are -50's, signals on the AP are at the target -60 on the AP, and SNR's on the AP are  all 30-35 (and 35-43 on the SM side).  But yet everyone disconnects periodically, sometimes every 4 hours or so, sometimes twice the next hour, sometimes 12 hour session times and then they several of them will disconnect all at once.

I'm certain it is interference - but our 10 year old StarOS stuff works through that interference OKish.  At least the CPE's don't disconnect and reconnect like this.  Regardless - I'm not reporting this as a 'should be able to deal with this interference' problem since ePMP usually does amazing in the face of interference..  I'm reporting this as a ''what tools do I use to figure out and mitigate this interfernce' report?

Before I bought my first ePMP's last year, the Cambium guy I talked to on the phone said that the eDetect could see all other radios in it's list, and plus there was also the Spectrum Analyzer as well.  BUT, the reality is - eDetect only lists radios on the same width, eDetect doesn't list UBNT or N-Streme or other types of WiFi Variants, and the reality is we can't run a Spectrum Analyzer over the air on a client.

So (again, I love my ePMP) but I'm really feeling like our hands are tied when there are problems like this.  It seems like the tools made to detect interference (eDetect and Spectrum Analyzer) don't work except unless we are using 20 Mhz channels and unless we drive to the customer's place to diagnose.

I have had same problem in the past, and I used a mix of tips:

1) continous ping from router behind the CPE to Internet to look latency and packet drop

2) execute many many Spectrum Analize, to find right place to keep on

3) trying to switch from Automatic Frequency Selection to manual, to show what happen with hinted channel

4) execute bandwidth test without no QoS or limiting rule to see how much a single CPE could bring in Mbps to sector and in the real to Internet.

What I could tell is following:

1) always put a Mikrotik router or AP behind Cambium CPE due a lack of software tools to check problems

2) try to execute a Spectrum Analisys with different gear (Cambium, Mimosa (best spectrum analize to me), Mikrotik)

3) try to play with frequency and width. In a crowded spectrum always use 20 Mhz channels even if you think that Cambium could do the miracle to avoid the interference. The real story is, try to find most clean channel you can is alwyas the best way to go

4) the bandwidth test should be executed from mikrotik to another mikrotik server, even one of the mikrotik public bandwidth test servers available. Better if you use TCP method with TCP Connection Count to 2

Finally, I post some images to show the difference between Mikrotik, Cambium and Mimosa Spectrum Analizer.

Give yourself an idea about that, considering that Mikrotik don't have a method to show a good defined image to show interference, Cambium ePMP is really a nightmare because you need to change mode to Spectrum, reboot the CPE, waiting for boot, start tool with Java with some problem regarding used browser, finally choose a small space where execute scan (you will loose about 20 minutes to do all that), while with Mimosa you have a continuosly spectrum live analisys that give you the chance to change frequency without loose the link thanks to GPS inside the radio used just for that feature.

More, with Mimosa you can see the local spectrum, the remote only spectrum and most useful, the combined spectrum that give you the 100% chance to find right best channel to use. 

Finally, Mimosa support extremely wide band from 4900 Mhz to 6200 Mhz. Even if you sometimes would find a slightly out of band clean channel surely for short time, you can use and perform some really interesting useful tests.

Thanks - those images are great.  

Can you tell me - are any of those products able to ignore their own signals?  What I mean is this - the old Cambium FSK 900 mhz gear we have, when you search for spectrum use from an SM, it shows the AP at -60 (or whatever it's connected at) and it's never been really all that useful to try to figure out if the current problem we are diagnosing is due to new/competitive noise overlapping the same channel.

It seems to me that the ideal SM Spectrum Analyzer (especially on a GPS Synced system in which you know the exact interval in which the AP will be TXing and in which interval in which it will be silent) would be able to know what signals were coming from the AP it was pointed at and be able to ignore those.

So - is there any difference there between the products?  Is anything able to remotely run a SA on the SM, and also to be able to show only 'other' signals and somehow listen only in it's AP's ''RX'' portion of it's frame, when the AP is silent?

Hi ninedd,

Actually the main difference lies in scanning frequencies.

eDetect just scan channel it is operating on.

In this case it can keep wireless session alive and filter own internal system packets and external systems packets.

Spectrum Analyzer is supposed to scan range of frequencies, in this case device should switch to another channels, because it has only one receiver.

Thank you.


@Fedor wrote:

eDetect just scan channel it is operating on.

In this case it can keep wireless session alive and filter own internal system packets and external systems packets.


The problem is - neither of these really are useful to help the solve client issues as I can see.  The eDetect only shows what might be interfering now, but only if it's a WiFi device in their home on the same channel and frequency and width that they are using now.

If our AP is on 10 Mhz widths for example, then there's no way to do an eDetect from their SM and see what channel their router is on if there home router is in 20 Mhz.  eDetect will say that there are no interferers, even if their router is on 2437 and is 20 Mhz wide and is a -47.  If we're on  2442 and we're 10 Mhz wide and the AP is seen at a -68, then their home router is absolutely going to be an issue, yet we can't tell that at all with eDetect or any of the ePMP diagnostic tools.

Or, if we are 20 Mhz wide and we're on 2462 and Customer A has a performance problem and if we do an eDetect and we can in fact see his router on 2462 and interfering - then one of the way we could solve that would be to change the channel that our AP is using.  BUT, from what I can tell, none of the ePMP diagnostic tools allow us to look at Customer A or Customer B or Customer C and know what will be interfering if we change the channel to 2417 Mhz.  So, even when we happen to be in the correct channel width to see their home router, we still can't see what channels they are using (unless it's currently interfering) and we can't predict what will happen on another channel.  The only way would be to randomly experiment - to change to that channel, then if everyone re-associated, to then test everyone's performance and to then see if anything in that CustomerA's house was interfering, and if anything in Customer B or C or D's house was interfering on the new channel.  Unless I'm missing something, there's no way to really diagnose problems that a customer is having without driving to their house every single time.

Again - I want to reiterate, I love ePMP - but how to diagnose and solve client problems is a puzzle to me.


SO for example - we have some gear that is...   maybe 12+ years old, really obsolete and horrible in many way.  BUT, when a client calls in with performance issues, right from the shop we can run a 'Super Site Survey' which can disconnect from the AP, switch to 5Mhz widths, do a 'site survey', then switch to 10 Mhz and then 20 and then reconnect and display the results.  There is a couple minutes of disconnection while running that test - BUT we can see everything WiFi flavoured that their CPE hears - regardless of the frequency it's on, regardless of the width it's on.  We know everything that could be currently interfering and everything that will interfere BEFORE we start changing channels on the AP.  To be clear, it doesn't report Ubnt stuff or ePMP stuff so it's no longer 'everything' - but it can report all channels and all channel widths in one list.

Virtually every wifi type plain cheap CPE's can show something like the list below, can can show us everything from 2412-2484 and even if it has to disconnect from the AP to do it, that's be way, way better than having to drive to every client's house to manually run a survey.

┌──────────── Site Survey for wpci1 ──────────┐
│Freq SSID Mac Sig Sec Mode Chains WMM SGI RX-STBC AMPD
│2412 SECTOR11 d1:1a -89 OFF LEG Yes
│2417 <ssid not advertised> 03:72 -71 OFF HT20 2/130M Yes 1-stream 65K
│2427 SECTOR22 d1:25 -87 OFF HT20 2/130M Yes 40 1-stream 65K
│2442 <ssid not advertised> b7:2e -59 OFF HT20 2/130M Yes 1-stream 65K
│2442 OTHERGUY-9 1c:3a -73 WEP LEG No
│2442 SECTOR-SOUTH b7:2e -60 OFF HT20 2/130M Yes 1-stream 65K
│2452 country connection 89:48 -48 RSN HT40- 2/300M Yes 20/40 65K
│2462 <ssid not advertised> a2:3f -89 OFF LEG Yes
│2462 SECTOR-NORTH af:7b -85 OFF HT20 2/130M Yes 1-stream 65K

3 Likes

ninedd is right: we need more tools to analyze interferences issue!

Agree with your statements.

Thank you for your feedbacks.

Actually we are moving in direction of Spectrum Analyzer functional improvements.

Hope we will have something new for you in next several releases.

Thank you.

1 Like

Can you tell us something about that :-) ? 

The most important thing for us is to have a live spectrum analyzer that continuosly show the spectrum status and live changing channel without loose the link.

More the vital feature is can see Local, Remote and Combined spectrum in way it permit to choose right channel to use to obtain best performance.

1 Like

I would like to see a more advance eDetect type of mechanism, that could find interferers that aren't on the exact same channel, and more importantly other channel widths.

Now that so many routers are defaulting to wider channel widths, it's getting to be very common to have an interferer on a channel that isn't the exact same channel, but does overlap. I wouldn't have a problem with having to take connection to the SM down for a minute while it runs the scan - in a lot of cases, eDetect type functionality can be more useful that a spectrum analyzer, since it can actually tell you not only that an interfering device is there, but in a lot of cases, it will tell you what it is too.

1 Like

@Mathew Howard wrote:

I would like to see a more advance eDetect type of mechanism, that could find interferers that aren't on the exact same channel, and more importantly other channel widths....    ...it's getting to be very common to have an interferer on a channel that isn't the exact same channel, but does overlap...   ...I wouldn't have a problem with having to take connection to the SM down for a minute while it runs the scan.


Absolutely - those are the keys.  If it needs to disconnect and do it's scan for 2 minutes or 5 minutes and then reconnect so that we can download the report - that'd be awesome and WAY better than having to drive to the client's house to do that.  I just wanna know all the info about all the devices you hear - ePMP devices and WiFi devices and even UBNT devices if it's possible to hear the UBNT preamble's, and whatever else you can hear in the house.

Even with our 10-15 year old non-Cambium generic WiFi gear, we often often find that one of the Customer's three routers in their house, or their ChromeCast is the culprit, even though it's on 20 Mhz widths and our AP/SM in in 10 Mhz widths.  When their ChromeCast is only 10 Mhz away, but it is 20 Mhz wide and is a -27 signal... that's what we need to know.

And, even if their ChromeCast or their router is 50 Mhz away, and maybe isn't interfering now, we need to know that BEFORE we change to that frequency on the AP/SM.  Right now, we are randomly trying things, without any idea before hand if that'll likely be better or worse at the CPE side of things.

1 Like