Re: CVS-2-2 NMApplet empty bar explained



On Fri, 2005-02-04 at 09:23 -0800, Jean Tourrilhes wrote:
> 	MAX_RSSI converted to dBm is some totally uninteresting
> value. It's going to be close to 0 dBm, and a value that has nothing
> much to do with real operation but just an arbitrary limit on the A->D
> converter used for RSSI sampling. On the other hand, MIN_RSSI is very
> relevant, so that's why we use that.

Jean,

Right now, WEXT says that (from the comments in iwlib.c) drivers should
use a max_qual->level = 0 to specify that the value is in dBm, and
max_qual->level > 0 for RSSI, right?  (ie Absolute and Relative as said
in iwlib.c/wireless.h)  In other words, the value in max_qual->level
specifies whether the value in qual->level and qual->noise are signed or
unsigned, right?  That seems a bit ambiguous to me, easy for driver
writers to get wrong.

(note that qual->qual & max_qual->qual aren't part of this discussion
since they should always be a percentage value that people can go 100 *
(qual->qual / max_qual->qual) with)

The problem right now is that drivers don't distinguish between valid &
invalid values in max_qual->level = 0.  As a person using the driver, I
don't know if the driver writer _meant_ to put 0 there, to tell me that
the values the card returns are in dBm, or whether the driver writer
didn't know _what_ to put there and just left it blank.  In some ways
that's a "fix the driver" problem to use IW_QUAL_LEVEL_INVALID, but it
would be nice to have some way to specify what the card means in the
levels it returns, either dBm or RSSI.  See the prism54 driver for
instance, they put a simple SNR in the qual->qual field, and stuff RSSI
into the qual->level field, yet max_qual->level is left at 0.  This is
wrong IMHO, but if the RSSI->dBm for the card isn't know, what should
the correct values in qual->level/qual->noise & max_qual->level be?

Either cards are going to return dBm (and hence max_qual->level = 0) or
RSSI (and hence max_qual->level > 0) (if they don't know RSSI->dBm
conversion tables/values), but at this time we don't know what because
of the ambiguity surrounding the max_qual->level field.  It would be
nice to have drivers set this explicitly somewhere...


Dan




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