On Mon, 2007-04-09 at 08:07 -0400, Dan Williams wrote:
> On Mon, 2007-04-09 at 00:43 -0400, Michael Wu wrote:
> > On Sunday 08 April 2007 23:54, Larry Finger wrote:
> > > Why would I want to do this?
> > Did it fix the output?
> >
> > > If the community agrees on anything, it is
> > > that the signal is given in dBm (i.e. a negative number) and that the rssi
> > > is a positive number.
> > Nope. dBm doesn't have to be negative, though it often is since most wireless
> > hardware isn't that powerful. RSSI is simply a number that's bigger for
> > stronger signals. It could be dBm, but it doesn't have to be. If you want a
> > stronger definition of RSSI, look at RCPI.
> >
> > > The firmware in the bcm43xx chips return a quantity
> > > that looks like an rssi with a received packet, and
> > > bcm43xx_rssi_postprocess turns that into a quantity that looks like dBm.
> > > Your patch reverses those designations and mixes up the two quantities.
> > > Again I ask "Why"?
> > >
> > Because of the naming/use of the statistics in mac80211 and WE. Signal ends up
> > getting assigned to (struct iw_quality).qual, which is actually just an
> > arbitrary link quality indicator, not dBm. Anything you care about can be put
> > there. (r)ssi gets assigned to (struct iw_quality).level, which is RSSI. WE
> > allows that and noise to be specified in either arbitrary units or dBm or
> > RCPI.
> >
> > Yes, I did reverse your conventions, but it makes more sense this way. (R)SSI
> > is always valid to assign to (struct iw_quality).level and signal ((struct
> > iw_quality).qual) is quite arbitrary and cannot be specified in specific
> > units.
> >
> > Signal should be probably be renamed to qual to make it more clear that it is
> > arbitrary.
>
> In WE, qual is arbitrary within a few limits:
>
> a) qual _must_ change on a linear scale
> b) a valid max_qual.qual must be set
> c) qual must fall within the bounds of [0, max_qual.qual] inclusive
d) max_qual.qual must be greater than 0
> If you report 'level' in dBm, you must set the IW_QUAL_DBM flag.
> Otherwise, 'level' _may_ be assumed to be RSSI. If 'level' is dBm,
> max_qual.level must be 0. If 'level' is RSSI, max_qual.level must be
> greater than 0, and level must fall within the bounds of [0,
> max_qual.level] inclusive. Replace 'level' with 'noise' here for the
> rules for noise.
>
> I don't particularly care if level/noise is RSSI _as long as_ you give
> the max RSSI for your part. Different radio parts have different max
> RSSI values, and if you're writing a driver you sure better know them or
> figure some reasonable ones out by experimentation. RSSI is entirely
> vendor defined and does _not_ conform to any rules. Therefore we need
> the max RSSI to get usable signal strength reports from your part.
RSSI doesn't conform to any rules _except_ that has a lower bound of 0
and an upper bound of the max for your part. WE happens to provide only
a u8 for the value, so if your vendor defines RSSI as > 255 you must
somehow stuff RSSI into a u8.
14.2.3.2 RXVECTOR RSSI
The receive signal strength indicator (RSSI) is an optional
parameter that has a value of 0 through RSSI Max.
Every vendor has a different max; Symbol's max is (at least used to be)
31. Cisco aironet's max is 100. Atheros' max appears to be 60.
Therefore, you must specify your max RSSI level in max_qual.level if you
use RSSI so that userspace tools can actually use your RSSI to produce
meaningful numbers.
Dan
> I know that 0 dBm isn't actually the upper bound, but in practice most
> people aren't going to get parts that go above that. 0 dBm should be
> considered a _limitation_ of WEXT that we obviously fix with
> cfg80211/nl80211 when we bring some sanity to signal strength reporting.
>
> Again, if you report level in RSSI, you must provide the max RSSI for
> your part in max_qual.level.
>
> Dan
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
