headers
Mohammed Shafi | 2 May 2011 10:00
Picon

Re: A problem about signal noise

On Sat, Apr 30, 2011 at 5:55 PM, kang haiyang
<hykang <at> dongniannetworks.com> wrote:
> hi all,
>
> I found the signal noise in packet (captured by a netgear card) with
> 5Ghz and
> 2.4Ghz is very different with the same ap and client.
>
> For 2.4Ghz (20Mhz bandwidth) , the average signal noise is about -80 ~
> -90 dbm,
> 5Ghz(40Mhz bandwith) is about -106dbm.
> The chip is ar9160 and with madwifi and proprietary HAL.
>
> Is it normal? I'm a really newbie about 802.11.

for AR9160 the noise floor can vary based on the bandwidth 20/40MHz
and as per docs, the values you are getting are acceptable(more than
this I don't know much detail). You can also try with ath9k.

>
> Thanks advance,
> kang haiyang
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel <at> lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
kang haiyang | 2 May 2011 10:20

Re: A problem about signal noise

Thanks a lot.

I got almost same noise floor with 20/40Mhz.
maybe i need to try with ath9k to see the result.

On 05/02/2011 04:00 PM, Mohammed Shafi wrote:
> for AR9160 the noise floor can vary based on the bandwidth 20/40MHz
> and as per docs, the values you are getting are acceptable(more than
> this I don't know much detail). You can also try with ath9k.
>
>> >
Permalink | Reply | 1 comment |
headers
Mohammed Shafi | 2 May 2011 10:40
Picon

Re: A problem about signal noise

On Mon, May 2, 2011 at 1:50 PM, kang haiyang
<hykang <at> dongniannetworks.com> wrote:
> Thanks a lot.
>
> I got almost same noise floor with 20/40Mhz.
> maybe i need to try with ath9k to see the result.

for ath9k, this command may help(please install iw)
 iw dev <devname> survey dump

>
> On 05/02/2011 04:00 PM, Mohammed Shafi wrote:
>> for AR9160 the noise floor can vary based on the bandwidth 20/40MHz
>> and as per docs, the values you are getting are acceptable(more than
>> this I don't know much detail). You can also try with ath9k.
>>
>>> >
>
Permalink | Reply | 0 comments |
headers
Eduard GV | 2 May 2011 23:46
Picon

More on signal and noise

Hi all,

Just three questions. I need per-packet SNR information and my first
guess was to inspect "last_signal" from debugfs. Values range from -30
to -60. last_signal file should contain signal (dBm) of last received
frame (from sta_info.h), right? That explains values obtained. But...

1) This value is computed as signal=ATH_DEFAULT_NOISE_FLOOR +
rx_stats->rs_rssi, which is confusing me. It would be explained if
rs_rssi is actually SNR (not RSSI) measured in dB. Am I wrong?

2) Why is NOISE_FLOOR fixed to -95 (dBm?). Noise varies randomly, e.g.
noise reported by iw survey dump vary from -91 to -101 dBm.

3) By the way, what do rs_rssi_ctlX and rs_rssi_extX (-1 < X < 3) measure?

Thank you!
Permalink | Reply | 12 comments |
headers
Luis R. Rodriguez | 3 May 2011 04:31
Favicon

Re: [PATCH 1/2] ath9k_htc: Dump base eeprom header for UB91/94/95

On Fri, Apr 29, 2011 at 02:54:17AM -0700, Sujith wrote:
> Christian Lamparter wrote:
> > Do you really think that everyone will be happy to recompile their stripped & heavily 
> > customised embedded kernels/or compat-wireless just to enable DEBUG and
> > waste precious resources? Even with a PC, this is not necessarily straightforward,
> > especially if the user has never done it before.
> 
> Yeah, this was the reasoning that I used to write a tool to dump eeprom
> data for PCI cards (using libpciaccess), and it is languishing internally. :)
> 
> I agree that there are benefits to having a userspace tool,
> maybe Luis' ath-utils tree can be used. But until then, it would be useful
> to have these in the driver.

Why didn't we ever open your tool up?

  Luis
Permalink | Reply | 1 comment |
headers
Sujith | 3 May 2011 04:59
Picon

Re: [PATCH 1/2] ath9k_htc: Dump base eeprom header for UB91/94/95

Luis R. Rodriguez wrote:
> On Fri, Apr 29, 2011 at 02:54:17AM -0700, Sujith wrote:
> > Christian Lamparter wrote:
> > > Do you really think that everyone will be happy to recompile their stripped & heavily 
> > > customised embedded kernels/or compat-wireless just to enable DEBUG and
> > > waste precious resources? Even with a PC, this is not necessarily straightforward,
> > > especially if the user has never done it before.
> > 
> > Yeah, this was the reasoning that I used to write a tool to dump eeprom
> > data for PCI cards (using libpciaccess), and it is languishing internally. :)
> > 
> > I agree that there are benefits to having a userspace tool,
> > maybe Luis' ath-utils tree can be used. But until then, it would be useful
> > to have these in the driver.
> 
> Why didn't we ever open your tool up?

Security through obscurity. :)

Sujith
Permalink | Reply | 0 comments |
headers
Alex Hacker | 3 May 2011 13:10
Picon

Re: More on signal and noise

On Mon, May 02, 2011 at 02:46:06PM -0700, Eduard GV wrote:
> Hi all,
> 
> Just three questions. I need per-packet SNR information and my first
> guess was to inspect "last_signal" from debugfs. Values range from -30
> to -60. last_signal file should contain signal (dBm) of last received
> frame (from sta_info.h), right? That explains values obtained. But...
> 
> 1) This value is computed as signal=ATH_DEFAULT_NOISE_FLOOR +
> rx_stats->rs_rssi, which is confusing me. It would be explained if
> rs_rssi is actually SNR (not RSSI) measured in dB. Am I wrong?
> 
> 2) Why is NOISE_FLOOR fixed to -95 (dBm?). Noise varies randomly, e.g.
> noise reported by iw survey dump vary from -91 to -101 dBm.
> 
> 3) By the way, what do rs_rssi_ctlX and rs_rssi_extX (-1 < X < 3) measure?
>
I'd spent some time trying to understand how these chips do the RSSI and noise
measurements and attempt to shortly explain my vision of this process.

Actually these chips unable to measure absolute signal level in dBm. This is
because of amplifiers in radio are implemented in CMOS technology. Real gain of
such gain stages are unpredictable and varies with temperature. Instead this
CMOS technology gives a simple way to realize stable gain step independrnt
from the temperature. So that Atheros chips can give as a valid SNR which is
incorrectly called RSSI in descriptor status fields. The value of noise
reported by "iw survery" is meaningless. This value obtained from a maximum
gain set by free running AGC within short period of time and then substracted
by baseband DSP from gain locked on packet's preamble. This process is
described in much details in Atheros' patent US 7,245,893 B1. Very interesting
(Continue reading)

Permalink | Reply | 9 comments |
headers
Pierre Parent | 3 May 2011 00:01
Picon
Picon
Favicon

Rewriting Epprom.

Sorry for taking 5 minutes of your time, but I'm desperately and vainly trying  
to rewrite eeprom (and more precisely subvendor ID) on a AR9281 WiFi card of 
mine (because of a HP bios blocking it). I've been able to find a lot of 
programs allowing to rewrite eeprom on ath5 cards (including ath_info), but 
I've found nothing for ath9 cards. 

I've tried to see, if I could not figure this out myself: I've studied eeprom.
[c h] files, but because of my lack of knowledge on WiFi cards, and the fact 
that there are almost no commentary in the code, I've been completely unable 
to understand anything in it. 

Would you have a clue on how to do this? 

Thank you in advance.
Permalink | Reply | 2 comments |
headers
Denis 'GNUtoo' Carikli | 3 May 2011 22:06
Favicon

Re: ath9k stopped queue bug

> if you want
> all the latest fixes you can try with latest wireless-testing  or
> compat-wireless
Thanks a lot, it works fine now(with compat-wireless).

Denis.
Permalink | Reply | 1 comment |
headers
Mohammed Shafi | 4 May 2011 07:30
Picon

Re: Rewriting Epprom.

On Tue, May 3, 2011 at 3:31 AM, Pierre Parent
<pierre.parent <at> insa-rouen.fr> wrote:
> Sorry for taking 5 minutes of your time, but I'm desperately and vainly trying
> to rewrite eeprom (and more precisely subvendor ID) on a AR9281 WiFi card of
> mine (because of a HP bios blocking it). I've been able to find a lot of
> programs allowing to rewrite eeprom on ath5 cards (including ath_info), but
> I've found nothing for ath9 cards.
>
> I've tried to see, if I could not figure this out myself: I've studied eeprom.
> [c h] files, but because of my lack of knowledge on WiFi cards, and the fact
> that there are almost no commentary in the code, I've been completely unable
> to understand anything in it.

does this helps grep -R "subvendorid" .

>
> Would you have a clue on how to do this?
>
> Thank you in advance.
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel <at> lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
Permalink | Reply | 0 comments |

Gmane