From: RHS Linux User <xxx@nei.mv.com>
To: Benoit PAPILLAULT <benoit.papillault@free.fr>
Cc: ath9k-devel <ath9k-devel@lists.ath9k.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] ath9k: noise floor calibration process
Date: Tue, 27 Apr 2010 20:01:08 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.3.95.1100427193637.9331F-100000@nei> (raw)
In-Reply-To: <4BD74B66.3030500@free.fr>
Hi All,
<preaching>
The chip *FOR SURE* *CANNOT* measure the thermal noise level!! It isn't
that sensitive. That said under some conditions it CAN measure the
local interference level which IS useful.
I am *VERY MUCH* in favor of making real time level measurements of
various parts of real packets easy to use! Troubleshooting becomes so
much easier :).
</preaching>
Great ideas !!
FWIW - I have on occasion used a low noise preamp to feed the chip.
Many more signals are detectable which "proves" the chip by itself *IS
NOT* that sensitive. Try it yourself !
Have fun,
Wiz
On Tue, 27 Apr 2010, Benoit PAPILLAULT wrote:
> Hello,
>
> In order to move forward with noise & signal reporting, I'd like to
> share my current understanding of the way ath9k HW is working before
> sending patches (unfortunately, I did the work before the introduction
> of ar9003... so I need to redo the work).
>
> The ultimate purpose of this work is to be able to measure signal levels
> (and noise if possible) as accurately as a spectrum analyzer or power meter.
>
> First, signal level reporting. It is reported in a per packet basis in
> RX descriptors. There are 7 fields:
> AR_RxRSSIAnt00 0x000000ff rs_rssi_ctl0
> AR_RxRSSIAnt01 0x0000ff00 rs_rssi_ctl1
> AR_RxRSSIAnt02 0x00ff0000 rs_rssi_ctl2
> AR_RxRSSIAnt10 0x000000ff rs_rssi_ext0
> AR_RxRSSIAnt11 0x0000ff00 rs_rssi_ext1
> AR_RxRSSIAnt12 0x00ff0000 rs_rssi_ext2
> AR_RxRSSICombined 0xff000000 rs_rssi
>
> Each value is for a 20 MHz wide channel, on the 3 RX chains. "ctl" is
> for the primary channel and "ext" is for the secondary channel (using
> the 802.11n words). The latter rs_rssi is the sum of the 6 previous
> value. However, since each value is dB, the sum is not an arithmetic
> sum. Each field is a signed value and the value -128 means that no
> measurement has been done (no RX chain, RX chain disabled, no secondary
> channel, ...). It seems that in some cases, the combined value is just
> plain wrong. Here are few examples:
>
> RSSI: ctl=(10,7,-128) ext=(-128,-128,-128) => 12 (11.76) correct
>
> RSSI: ctl=(38,29,-128) ext=(69,-84,-101) => -22 incorrect!!!
>
>
> Next, noise floor calibration. From what I understand, signal levels is
> measured using the AGC + RX amplifiers gain (RF, IF and BB). However,
> the various gains are not really accurate, only the relative gain are
> accurate. This means that reading a signal value of -100dBm might not
> exactly means -100dBm. There is a delta between real signal and measured
> value. In order to know this value, we need a calibration process with a
> known signal.
>
> One know signal is thermal noise. Thermal noise is generated in any
> resistor and can be computed using the well know value N = kTB. For a 20
> MHz bandwidth, this gives -101dBm. If the HW tries to measure signal
> strength when the network is supposed to be idle (during SIFS) and with
> RX/TX switch disabled (?), then it will in fact measure the thermal
> noise at the RX input.
>
> So, we have :
>
> Real noise (-101dBm) = Measured noise + delta
>
> There are type of registers to control noise floor calibration :
>
> - control register at 0x9860 (AR_PHY_AGC_CONTROL)
>
> This register allows 3 differents operations :
>
> 1. start noise floor measurement
>
> write AR_PHY_MAXCCA_PWR (AR_PHY_CCA & 0x000001ff) : this is apparently
> a max value
> for noise floor
> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
>
> When channel has been changed however, the noise floor needs to be
> updated immediately, so AR_PHY_AGC_CONTROL_NO_UPDATE_NF should be
> cleared in this particular case. Otherwise, the chip is no longer
> receiving (problem since CCA is defined with noise floor as reference).
>
> 2. read noise floor measurement result
>
> check REG_READ(ah, AR_PHY_AGC_CONTROL) & AR_PHY_AGC_CONTROL_NF
> if 0 (noise floor calibration is finished), read AR_PHY_MINCCA_PWR :
> nf = MS(REG_READ(ah, AR_PHY_CCA), AR_PHY_MINCCA_PWR = 0x0ff80000)
>
> 3. write noise floor reference
>
> write AR_PHY_MAXCCA_PWR (the value has not the same meaning as
> operation 1!)
> REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_ENABLE_NF);
> REG_CLR_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NO_UPDATE_NF);
> REG_SET_BIT(ah, AR_PHY_AGC_CONTROL, AR_PHY_AGC_CONTROL_NF);
>
> - data register at 0x9864 (AR_PHY_CCA, + more location for other RX chains)
>
> The fields are different for AR9280+ chipsets, but the mechanism is
> the same.
>
> AR_PHY_MAXCCA_PWR 0x000001ff (half dBm unit!)
> AR_PHY_CCA_THRESH62 0x0007f000
> AR_PHY_MINCCA_PWR 0x0ff80000
>
> Now, we have :
>
> Real signal = Measured signal + delta
> = RSSI + Noise floor + delta
> = RSSI + (-101 dBm)
>
> Real noise is not thermal noise. There are a lot of definition for noise
> since noise is NOT signal. Of course, noise includes thermal noise.
> Since the noise measured by the chip is variable, I think we could do :
>
> - Noise floor = minimum (Noise floor measures)
> - Noise = moving average (Noise floor measures) + delta
> with delta = (-101 dBm) - Noise floor
>
> I'd like to get comments before sending patches. Since ath5k and ath9k
> are quite close, I'm pretty sure a similar (if not same) process is used
> on ath5k.
>
> Regards,
> Benoit
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
next prev parent reply other threads:[~2010-04-28 1:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-27 20:39 ath9k: noise floor calibration process Benoit PAPILLAULT
2010-04-28 0:01 ` RHS Linux User [this message]
2010-04-28 6:04 ` [ath9k-devel] " Benoit PAPILLAULT
2010-04-28 9:24 ` RHS Linux User
2010-04-28 12:53 ` Holger Schurig
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=Pine.LNX.3.95.1100427193637.9331F-100000@nei \
--to=xxx@nei.mv.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=benoit.papillault@free.fr \
--cc=linux-wireless@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).