Re: CVS-2-2 NMApplet empty bar explained

Take a look at the next message I sent about patching the NM nm_wireless_qual_to_percent function. If a driver does not report max_qual->level and max->qual->noise, make some good guess. The physical lower limit for what a card can do is about -96 dBm. The upper limit varies but is always less than -10 dBm. For the ipw2200, -20 dBm is about right. Percentage is at best a rough indicator and does not directly relate to a physical quantity so I don't think it matters that much to get it "exactly right". If the driver does not specify max_qual->level and max->qual->noise, how about setting

max_qual->level to 221 (-35 dBm)
max_qual->noise to 161 (-95 dBm)

and use a linear model for percentage like the one I put in the patch message. The 70 coefficient may need some adjustment for these values guessed values.

The CLAMP function will take care of any overshoot.

Dan Williams wrote:

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


Bill Moss
Professor, Mathematical Sciences
Clemson University

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