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 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. 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
