Dan Williams wrote:
To me, it looks like you're trying to use dBm rather than RSSI here. In
that case, you have to set range->max_qual.level to 0, because the upper
bound of dBm is indeed 0. If you are using negative values _anywhere_
in your code for quality, you're almost certainly using dBm, not RSSI,
or something is very wrong.
Print out the value of 'average' from handle_irq_noise() both when close
and far away from the AP. It looks to me like the final calculations
there come out in dBm given the fact that (a) average is negative, and
(b) that average is in the range of acceptable dBm numbers. So:
1. set your stats->max_qual.level = 0
2. set bcm->stats.link_quality = average
3. Do link quality calculation on signal and noise; you can't just be
linear here though, since a noise floor of -100 with a signal of -90 is
in reality better than 10% signal; it's actually pretty OK. Each -1 dBm
step near the noise floor counts for more % than a -1 dBm increase near
the best signal level. You have to weight the bottom of the scale WRT
percentage to get values that make sense.
Thanks for explaining how to get dBm into these fields. The comments in include/linux/wireless.h are
confusing.
The quantity listed in stats.rssi has been processed into a dBm value in a routine called
bcm43xx_rssi_postprocess, which I need to mention in the comments. The calculation is more black
magic from the clean-room group's reverse engineering of the Mips driver. I changed the name of the
constant from RSSI_MAX to RX_POWER_MAX, which I estimate to be -10 dBm (see below).
As I move away from the AP, I get the following results:
Dist. "rssi" "average" Link Quality Notes
.3 m -14 -64 96/100 Nearly on top of AP
2 m -27 -62 83/100 Direct line of sight
15 m -55 -65 55/100 Bounce down hallway and/or
through wall
20 m -66 -66 44/100 Like 15m point, but through
plate glass window
- 35% packet loss with ping
The "Link Quality" above comes from 100 - "rssi" - RX_POWER_MAX, where
RX_POWER_MAX is -10.
As "average" does not change, clearly the link quality cannot be derived from that value. It seems
to me that the processed value in the stats.rssi field is not too bad an estimate of the qual.level
(in dBm). The value from "average" is also not a good estimate of the noise, but it is the best I
have at the moment. Clearly, the reported value of qual.qual (Link quality) needs to be adjusted
ipw2200 for example reports -53 dBm near the AP, with noise floor of -83
dBm in a fairly spectrum-crowded area. That translates into what
ipw2200 reports as a 75% signal, which seems a bit off, but gives you an
idea. You'll never get near 0 dBm, since there's already 10s of dBm
loss when the signal has to cross any air at all.
I'm now getting a similar result with an 85% signal at 2 m. The main difference is that both signal
and noise seem to be shifted up by about 20 dBm. As these are logarithmic quantities, S/N is
preserved through this offset. My feeling is that these statistics have no absolute meaning, but are
good as relative indicators. When the left-most bar in the Wireless Network Information applet in
the KDE taskbar changes from green to yellow, I know that the signal is degraded.
Thanks for your comments. They made me dig a lot deeper into the numbers.
Larry
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
