You are here WiFI Scan Strangeness

7 posts / 0 new
Last post
WX4LTG WiFI Scan Strangeness
If I configure my node (a NanoStation M2) to use Channel 1, the list of displayed SSIDs in "WiFi Scan" is very, very different than the list I see with the NSM2 configured to use Channel 6. There's a marginal node I can see on Channel 6 when I've changed my own settings to use that channel, but it's entirely invisible if I've configured to use Channel 1.

Just a bit weird.
AE6XE's picture
Are all the nodes in question
Are all the nodes in question on the same channel width?    Mesh nodes do not see other signals on different channel widths in wifi scan.  The channel width is not something that can be changed "on the fly" so readily like changing channel in the driver, consequently it would take more effort to implement this capability.  
No change in channel width
The only parameter changed is the channel number - which results in radically different lists of SSIDs.
AE6XE's picture
This is very interesting.   

This is very interesting.    I speculate that this is what is happening.   The driver is building a history of the environment on a given channel and begins to better tune the receiver to operate.  There are 3 AGC steps from antenna->IF>Baseband in the receiver and the logic tunes for a specified low, high, and signal size going into the baseband,  based on things like environment noise and packet error rates.  In the 'baseband', the logic does the analog to digital conversion, protocol identification, and packet decoding.     There's also other logic dealing with ambient noise to desensitize and adjust other parameters in the receiver.    I suspect that the receiver has become better tuned to receiving signals on the channel it is on.  When a wifi scan occurs on other channels, it has no history of the environment on those channels and does not optimally receive the signals.    

Are the different SSIDs received on the different channels from signals on the respective channels (or nearby channels)?  Is there a pattern here?


I had the notion that the
I had the notion that the device was tuning itself to the configured channel, so I've been running the scan at intervals today. It definitely appears that there is higher sensitivity to the channel configured as well as the nearest adjacent channel. When I tune to 1, I see mostly 1, 2, and 3. When I tune to 6, I see mostly 4, 6, 7, and 8.

Et cetera.
Joe  please  remember that
Joe  please  remember that the AGC and ANI data data is thrown out during a scan. No historical data is used.

As for further away remember multiple items come in to play here during a WIFI Scan:

ON the current channel every beacon received on channel is added to the internal wifi scan list as a last seen beacon.  This means ON CHANNEL PASSIVE scans are essentially running constantly (just not actively) this means on channel will always have an advantage for wifi scanning.

During a wifi scan a node can be OFF CHANNEL only so long before its required to get back on channel to receive and send data. During this time wifi scan has to do:
1) Slew the frequency from primary channel to scan channel -- The further you have to slew the longer it will take as you to change frequency, check the frequency is correct, slew again and repeat until you are exactly there.
2) Send a packet out asking all devices around to respond they are active
3) wait for a response to the active probe or a random beacon packet from devices that didn't see the probe or don't respond to probes.
4) Slew back to original frequency and process data.

A device is only allowed to be off channel for so long at any give time (Not sure exact length off hand)

If one wants to do a real survey they need to do it with wifi analysis equipment, a wifi scan is NOT a substitute to a full band spectrum analysis and data logging/decoding.
AE6XE's picture
Yes, ANI does not carry along
Yes, ANI does not carry along history data of a channel for a scan.  But consider if ANI was turned off.  There's more to the story with calibrations.  I've not yet  parsed the code to rule out if other historical channel data is involved.   For example, ath9k_init_nfcal_hist_buffer(ah, chan).  Can you rule this out?

What's interesting is that we see more signals in a scan around the current channel.  The great thing about speculation is that it is guessing, as I continue to speculate :) :     The data does suggest that historical data is not involved, otherwise we'd see more equal distribution of signals for all non-self-channels.    Maybe the cluster is because adjacent channels are more closely characterized by the current channel environment--and that is what is being used, vs a default or historical reference point.


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer