The current wireless statistics for the RTL8187 poorly indicate the sig=
nal
strength and quality. With testing, I found that the AGC value is inver=
sely
correlated with the strength as in the RTL8187B. By implementing a simi=
lar
calculation, much more code becomes common to the two devices.
Signed-off-by: Larry Finger <[email protected]>
Tested by: Mart=C3=ADn Ernesto Barreyro <[email protected]>
---
John,
This is 2.6.29 material.
Larry
---
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -313,29 +313,14 @@ static void rtl8187_rx_cb(struct urb *ur
struct rtl8187_rx_hdr *hdr =3D
(typeof(hdr))(skb_tail_pointer(skb) - sizeof(*hdr));
flags =3D le32_to_cpu(hdr->flags);
- signal =3D hdr->signal & 0x7f;
+ /* As with the RTL8187B below, the AGC is used to calculate
+ * signal strength and quality. In this case, the scaling
+ * constants are derived from the output of p54usb.
+ */
+ quality =3D 130 - ((41 * hdr->agc) >> 6);
+ signal =3D -4 - ((27 * hdr->agc) >> 6);
rx_status.antenna =3D (hdr->signal >> 7) & 1;
- rx_status.noise =3D hdr->noise;
rx_status.mactime =3D le64_to_cpu(hdr->mac_time);
- priv->quality =3D signal;
- rx_status.qual =3D priv->quality;
- priv->noise =3D hdr->noise;
- rate =3D (flags >> 20) & 0xF;
- if (rate > 3) { /* OFDM rate */
- if (signal > 90)
- signal =3D 90;
- else if (signal < 25)
- signal =3D 25;
- signal =3D 90 - signal;
- } else { /* CCK rate */
- if (signal > 95)
- signal =3D 95;
- else if (signal < 30)
- signal =3D 30;
- signal =3D 95 - signal;
- }
- rx_status.signal =3D signal;
- priv->signal =3D signal;
} else {
struct rtl8187b_rx_hdr *hdr =3D
(typeof(hdr))(skb_tail_pointer(skb) - sizeof(*hdr));
@@ -353,18 +338,18 @@ static void rtl8187_rx_cb(struct urb *ur
*/
flags =3D le32_to_cpu(hdr->flags);
quality =3D 170 - hdr->agc;
- if (quality > 100)
- quality =3D 100;
signal =3D 14 - hdr->agc / 2;
- rx_status.qual =3D quality;
- priv->quality =3D quality;
- rx_status.signal =3D signal;
- priv->signal =3D signal;
rx_status.antenna =3D (hdr->rssi >> 7) & 1;
rx_status.mactime =3D le64_to_cpu(hdr->mac_time);
- rate =3D (flags >> 20) & 0xF;
}
=20
+ if (quality > 100)
+ quality =3D 100;
+ rx_status.qual =3D quality;
+ priv->quality =3D quality;
+ rx_status.signal =3D signal;
+ priv->signal =3D signal;
+ rate =3D (flags >> 20) & 0xF;
skb_trim(skb, flags & 0x0FFF);
rx_status.rate_idx =3D rate;
rx_status.freq =3D dev->conf.channel->center_freq;
@@ -1294,6 +1279,7 @@ static int __devinit rtl8187_probe(struc
=20
priv->mode =3D NL80211_IFTYPE_MONITOR;
dev->flags =3D IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
+ IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_RX_INCLUDES_FCS;
=20
eeprom.data =3D dev;
@@ -1409,13 +1395,8 @@ static int __devinit rtl8187_probe(struc
(*channel++).hw_value =3D txpwr >> 8;
}
=20
- if (priv->is_rtl8187b) {
+ if (priv->is_rtl8187b)
printk(KERN_WARNING "rtl8187: 8187B chip detected.\n");
- dev->flags |=3D IEEE80211_HW_SIGNAL_DBM;
- } else {
- dev->flags |=3D IEEE80211_HW_SIGNAL_UNSPEC;
- dev->max_signal =3D 65;
- }
=20
/*
* XXX: Once this driver supports anything that requires
On Thu, Dec 4, 2008 at 1:57 PM, Christian Lamparter <[email protected]> w=
rote:
> On Thursday 04 December 2008 13:44:09 Stefanik G=E1bor wrote:
>
>> BTW using RTL8187B's scaling constants for RTL8187L also work well
>> with this patch - I get almost identical readings from my BCM4318 an=
d
>> my RTL8187L. (I haven't yet submitted my version of the patch becaus=
e
>> it's pretty messy, with #if 0'd code and such.) I wonder whether b43
>> or p54usb is more correct... However, it looks like the same algorit=
hm
>> is applicable for both RTL8187 variants.
>>
> probably b43. p54usb uses static scaling constants to calculate
> signal & noise dbm, instead of finding the correct values from the de=
vice eeprom
> (Note: Link Quality doesn't substract the noise so it could be off ev=
en more).
>
> However, in my testing it was only a few +/- dbm(s), what's your read=
ing?
>
=46rom an AP ~5M from my antenna, both cards report around -45dBm. I
haven't tested the p54usb-based algorithm yet.
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Stefanik G=E1bor wrote:
>=20
>>From an AP ~5M from my antenna, both cards report around -45dBm. I
> haven't tested the p54usb-based algorithm yet.
Both the RTL8187 and the RTL8187B "calibrations" were done using a sing=
le sample
of each device, which is probably risky, but the best I could do.
Is it possible for you to send me the quality and signal strength that =
you
obtain for the RTL8187 at distances of a few cm, 3m and 10m from the AP=
? Please
include which algorithm was used in the conversion.
Thanks,
Larry
On Thu, Dec 4, 2008 at 5:21 AM, Larry Finger <[email protected]=
> wrote:
> The current wireless statistics for the RTL8187 poorly indicate the s=
ignal
> strength and quality. With testing, I found that the AGC value is inv=
ersely
> correlated with the strength as in the RTL8187B. By implementing a si=
milar
> calculation, much more code becomes common to the two devices.
>
> Signed-off-by: Larry Finger <[email protected]>
> Tested by: Mart=EDn Ernesto Barreyro <[email protected]>
> ---
>
> John,
>
> This is 2.6.29 material.
>
> Larry
> ---
>
> Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_dev.c
> +++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_dev.c
> @@ -313,29 +313,14 @@ static void rtl8187_rx_cb(struct urb *ur
> struct rtl8187_rx_hdr *hdr =3D
> (typeof(hdr))(skb_tail_pointer(skb) - sizeof(*=
hdr));
> flags =3D le32_to_cpu(hdr->flags);
> - signal =3D hdr->signal & 0x7f;
> + /* As with the RTL8187B below, the AGC is used to cal=
culate
> + * signal strength and quality. In this case, the sca=
ling
> + * constants are derived from the output of p54usb.
> + */
> + quality =3D 130 - ((41 * hdr->agc) >> 6);
> + signal =3D -4 - ((27 * hdr->agc) >> 6);
> rx_status.antenna =3D (hdr->signal >> 7) & 1;
> - rx_status.noise =3D hdr->noise;
> rx_status.mactime =3D le64_to_cpu(hdr->mac_time);
> - priv->quality =3D signal;
> - rx_status.qual =3D priv->quality;
> - priv->noise =3D hdr->noise;
> - rate =3D (flags >> 20) & 0xF;
> - if (rate > 3) { /* OFDM rate */
> - if (signal > 90)
> - signal =3D 90;
> - else if (signal < 25)
> - signal =3D 25;
> - signal =3D 90 - signal;
> - } else { /* CCK rate */
> - if (signal > 95)
> - signal =3D 95;
> - else if (signal < 30)
> - signal =3D 30;
> - signal =3D 95 - signal;
> - }
> - rx_status.signal =3D signal;
> - priv->signal =3D signal;
> } else {
> struct rtl8187b_rx_hdr *hdr =3D
> (typeof(hdr))(skb_tail_pointer(skb) - sizeof(*=
hdr));
> @@ -353,18 +338,18 @@ static void rtl8187_rx_cb(struct urb *ur
> */
> flags =3D le32_to_cpu(hdr->flags);
> quality =3D 170 - hdr->agc;
> - if (quality > 100)
> - quality =3D 100;
> signal =3D 14 - hdr->agc / 2;
> - rx_status.qual =3D quality;
> - priv->quality =3D quality;
> - rx_status.signal =3D signal;
> - priv->signal =3D signal;
> rx_status.antenna =3D (hdr->rssi >> 7) & 1;
> rx_status.mactime =3D le64_to_cpu(hdr->mac_time);
> - rate =3D (flags >> 20) & 0xF;
> }
>
> + if (quality > 100)
> + quality =3D 100;
> + rx_status.qual =3D quality;
> + priv->quality =3D quality;
> + rx_status.signal =3D signal;
> + priv->signal =3D signal;
> + rate =3D (flags >> 20) & 0xF;
> skb_trim(skb, flags & 0x0FFF);
> rx_status.rate_idx =3D rate;
> rx_status.freq =3D dev->conf.channel->center_freq;
> @@ -1294,6 +1279,7 @@ static int __devinit rtl8187_probe(struc
>
> priv->mode =3D NL80211_IFTYPE_MONITOR;
> dev->flags =3D IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
> + IEEE80211_HW_SIGNAL_DBM |
> IEEE80211_HW_RX_INCLUDES_FCS;
>
> eeprom.data =3D dev;
> @@ -1409,13 +1395,8 @@ static int __devinit rtl8187_probe(struc
> (*channel++).hw_value =3D txpwr >> 8;
> }
>
> - if (priv->is_rtl8187b) {
> + if (priv->is_rtl8187b)
> printk(KERN_WARNING "rtl8187: 8187B chip detected.\n")=
;
> - dev->flags |=3D IEEE80211_HW_SIGNAL_DBM;
> - } else {
> - dev->flags |=3D IEEE80211_HW_SIGNAL_UNSPEC;
> - dev->max_signal =3D 65;
> - }
>
> /*
> * XXX: Once this driver supports anything that requires
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wirel=
ess" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
BTW using RTL8187B's scaling constants for RTL8187L also work well
with this patch - I get almost identical readings from my BCM4318 and
my RTL8187L. (I haven't yet submitted my version of the patch because
it's pretty messy, with #if 0'd code and such.) I wonder whether b43
or p54usb is more correct... However, it looks like the same algorithm
is applicable for both RTL8187 variants.
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--- On Thu, 4/12/08, Larry Finger <[email protected]> wrote:
> From: Larry Finger <[email protected]>
> Subject: [PATCH V2] rtl8187: Improve wireless statistics for RTL8187
> To: "John W Linville" <[email protected]>
> Cc: "Herton Ronaldo Krzesinski" <[email protected]>, "Hin-Tak Le=
ung" <[email protected]>, [email protected], linux-wir=
[email protected]
> Date: Thursday, 4 December, 2008, 4:21 AM
> The current wireless statistics for the RTL8187 poorly
> indicate the signal
> strength and quality. With testing, I found that the AGC
> value is inversely
> correlated with the strength as in the RTL8187B. By
> implementing a similar
> calculation, much more code becomes common to the two
> devices.
>=20
> Signed-off-by: Larry Finger
> <[email protected]>
> Tested by: Mart=EDn Ernesto Barreyro
> <[email protected]>
Acked-by: Hin-Tak Leung <[email protected]>
Looks cleaner.
Hin-Tak
=20
On Thursday 04 December 2008 13:44:09 Stefanik G=E1bor wrote:
> BTW using RTL8187B's scaling constants for RTL8187L also work well
> with this patch - I get almost identical readings from my BCM4318 and
> my RTL8187L. (I haven't yet submitted my version of the patch because
> it's pretty messy, with #if 0'd code and such.) I wonder whether b43
> or p54usb is more correct... However, it looks like the same algorith=
m
> is applicable for both RTL8187 variants.
>=20
probably b43. p54usb uses static scaling constants to calculate
signal & noise dbm, instead of finding the correct values from the devi=
ce eeprom
(Note: Link Quality doesn't substract the noise so it could be off even=
more).
However, in my testing it was only a few +/- dbm(s), what's your readin=
g?
On Thu, Dec 4, 2008 at 3:06 PM, Larry Finger <[email protected]=
> wrote:
> Stefanik G=E1bor wrote:
>>
>>>From an AP ~5M from my antenna, both cards report around -45dBm. I
>> haven't tested the p54usb-based algorithm yet.
>
> Both the RTL8187 and the RTL8187B "calibrations" were done using a si=
ngle sample
> of each device, which is probably risky, but the best I could do.
>
> Is it possible for you to send me the quality and signal strength tha=
t you
> obtain for the RTL8187 at distances of a few cm, 3m and 10m from the =
AP? Please
> include which algorithm was used in the conversion.
>
> Thanks,
>
> Larry
>
>
>
Unfortunately that is not possible, as the RTL8187 is on the onboard
WiFi module of a desktop (P5K Premium), while the AP is a combined
ADSL modem+wireless router, so it must be placed near the ADSL wall
socket.
However, I am planning to get an Alfa AWUS036H (high-power RTL8187L
with known sensitivity levels) and an Argtek ARG-U25g (similar to the
Alfa, just RTL8187B-based), so I will be able to check the distance
where the connection drops (which corresponds to the sensitivy
levels).
--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Larry Finger <Larry.Finger@...> writes:
> Is it possible for you to send me the quality and signal strength that you
> obtain for the RTL8187 at distances of a few cm, 3m and 10m from the AP? Please
> include which algorithm was used in the conversion.
Hello.
I really new to that, but I would be glad to help !
I had big troubles with vanilla kernel drivers, but that's not news.
I'm currently compiling compat-wireless-2009-04-04 and I hope results will be
better.
My device :
Bus 001 Device 004: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless
Adapter
It's on a laptop so I can do every kind of test you can imagine ! ;-)
Regards,
Hamlet
PS. Please reply to my address since I'm not on the mailing-list...
Tell me if you think I should !
Hamlet wrote:
> Larry Finger <Larry.Finger@...> writes:
>
>> Is it possible for you to send me the quality and signal strength that you
>> obtain for the RTL8187 at distances of a few cm, 3m and 10m from the AP? Please
>> include which algorithm was used in the conversion.
>
> Hello.
> I really new to that, but I would be glad to help !
> I had big troubles with vanilla kernel drivers, but that's not news.
> I'm currently compiling compat-wireless-2009-04-04 and I hope results will be
> better.
>
> My device :
> Bus 001 Device 004: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless
> Adapter
>
> It's on a laptop so I can do every kind of test you can imagine ! ;-)
>
> Regards,
> Hamlet
>
> PS. Please reply to my address since I'm not on the mailing-list...
> Tell me if you think I should !
Since I requested that data, I got my own RTL8187L and filled in the data.
Compat-wireless has the latest version of the driver. In addition, the latest
version of mac80211 no longer needs that information, and calculates its own
signal strength and link quality.
The only test that you need to do is check that the rate is automatically
adjusted up from 1 Mb/s. Some flavors of RTL8187L's seem to have a problem in
setting the rate. Mine does not.
Larry