Re: CVS-2-2 NMApplet empty bar explained

[Bill Moss <bmoss clemson edu>]

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.
>
> http://is.med.ohio-state.edu/Wireless%20FAQ.htm
>
> 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
> continues.
>
> Dan
>
>
>  

--
Bill Moss
Professor, Mathematical Sciences
Clemson University