Re: CVS-2-2 NMApplet empty bar explained

On Fri, 2005-02-04 at 01:00 -0500, Bill Moss wrote:
> Now look at the results for the scanned AP's (list of one here). qual 
> and noise are reported as 0. This is why the CVS-2-2 NMApplet bar is 
> empty for the ipw2200 driver. NM uses the qual value of zero to create 
> the bar length. We can convert the level of 198 to -58 dBm but NM has no 
> idea how ipw2200 would convert this into a percentage. to make matters 
> worse the dBm range varies from driver to driver. We are stuck. There is 
> no way the NM nm_wireless_qual_to_percent function can deal with this. A 
> new nm_wireless_level_to_percent function could be created to do this 
> conversion but it would be guess work at best and impossible to 
> normalize across all drivers.

More or less correct... I spent much of last night looking at stuff
online trying to figure out ways to be able to use noise & signal levels
for something, but without much luck.  Drivers simply have to report the
noise, and many (like Atheros) hardcode the noise levels.  This doesn't
work well for the drivers because they have to support a couple
different actual chips, and sometimes the same value doesn't necessarily
work for all chips.  The real solution is to have drivers report their
own quality based off RSSI (which all cards MUST have to be 802.11b
compliant) and max RSSI.

Also, we pretty much need the max_qual.level as well if there's not
quality information.  As measured on my Netgear WG511T right next to my
Linksys WRT54G, that was a fairly consistent -39dBm (saw a -30 once
too).  However, unless I'm wrong, this varies by access point since each
access point puts out different levels of power and have different
antennas, both of which affect the actual received signal power on the
card.  However, using that max_qual.level value, we could take the noise
level of -95dBm and we have an upper and lower bound of some sort.

Interestingly enough, I found this page that appears to describe what
Windows uses, at least for some cards.  We may in the end need to do
some approximation of this to achieve a signal "quality" measurement
from just signal and noise.

Cards use the SNR to determine what speed to drop down to, so some
combination of current card speed and SNR may work for us in the absence
of actual quality information reported from the driver.  Only as a last
resort of course.  But using card speed doesn't help us for scanned
access points, since we're not connected to them :(  The search


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]