All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peizhao Hu <peizhao.research@gmail.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] More on signal and noise
Date: Fri, 06 May 2011 11:49:29 +1000	[thread overview]
Message-ID: <4DC353A9.3050801@gmail.com> (raw)
In-Reply-To: <20110503111016.GA23612@infinet.ru>

Does this CMOS assumption apply to ath5k as well?

I thought ath5k has noise recalibration which tune the noise floor 
accordingly (which seems to be true from our experiments). In madwifi 
the noise floor is fixed at -95 or -96, but the ath5k introduces the ani 
and noise recalibration.

But the rs_rssi is SNR??

regards;

Peizhao


On 03/05/11 21:10, Alex Hacker wrote:
> 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
> document, should I say. I'm also impressed with 55 claims at the end.
>
> Now how the absolute RSSI is  calculated in ath9k. Instead of using meaningless
> noisefloor it adds predefined value of -95 dBm to each SNR measured in
> baseband. I will try to guess how this value are calculated. The basic equation
> for calculating noise power at the antenna input is: Pn = k*T*F*B. Where: k -
> Boltzmann constant, T - input noise temperature, F - noise factor of the
> receiver and B - the bandwidth.
> The temperature variation is less then 1dB within working range 250..330K, so
> can be ignored. If we assume T = 300K, F = ~2 for LNAs used in Atheros
> reference boards, we got the following values: 166 fW = -98dBm in 20MHz
> bandwith and 331 fW = -95 dBm in 40 MHz bandwith.
>
> The value -95 programmed in ath9k is valid reference noise level for 40MHz, but
> for 20MHz it should be lowered by 3dB. This difference in measured RSSI can be
> easily shown in monitor mode observing signal level from 20MHz station. When
> monitor node is switched between HT20 and HT40 the RSSI will change by 3dB.
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

  reply	other threads:[~2011-05-06  1:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 21:46 [ath9k-devel] More on signal and noise Eduard GV
2011-05-03 11:10 ` Alex Hacker
2011-05-06  1:49   ` Peizhao Hu [this message]
2011-05-06  3:45     ` hacker at AShevkov.infinet.ru
2011-05-06  4:06     ` Alex Hacker
2011-05-06  4:41       ` Alex Hacker
2011-05-18  0:04   ` Eduard GV
2011-05-20  4:20     ` Alex Hacker
2011-05-20  4:46       ` Adrian Chadd
2011-05-20  5:54         ` Alex Hacker
2012-06-07  2:50           ` MaYongsen
2011-06-09 22:46 ` Eduard GV
2011-06-09 22:56   ` Daniel Halperin
2014-01-10 10:00     ` syed
2014-01-10 17:45       ` Adrian Chadd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DC353A9.3050801@gmail.com \
    --to=peizhao.research@gmail.com \
    --cc=ath9k-devel@lists.ath9k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.