[ath9k-devel] More on signal and noise

[ath9k-devel] More on signal and noise

[Eduard GV]

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!

[ath9k-devel] More on signal and noise

[Alex Hacker]

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] More on signal and noise

[Peizhao Hu]

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

[ath9k-devel] More on signal and noise

[hacker at AShevkov.infinet.ru]

Yes, the AR5416 and so on chips uses the same Athersos CMOS technology and
same principle of RSSI/noise measurements.

The noise calibration is the process of periodic measuring minimum received
power in channel, averaging it and writing back to HW. This averaged value is
then used by HW to calculate SNR (rs_rssi). This valie analogues to AR92xx
measured in dB to unknown (temperature dependent) reference, not mW.

The fact that NF value on ath5k chips is near the real dBm noise level should
not lead to conclude that it is the same, it is incorrect.

Have a nice day!

[ath9k-devel] More on signal and noise

[Alex Hacker]

Yes, the AR5416 and so on chips uses the same Athersos CMOS technology and
same principle of RSSI/noise measurements.

The noise calibration is the process of periodic measuring minimum received
power in channel, averaging it and writing back to HW. This averaged value is
then used by HW to calculate SNR (rs_rssi). This valie analogues to AR92xx
measured in dB to unknown (temperature dependent) reference, not mW.

The fact that NF value on ath5k chips is near the real dBm noise level should
not lead to conclude that it is the same, it is incorrect.

Have a nice day!

[ath9k-devel] More on signal and noise

[Alex Hacker]

On Fri, May 06, 2011 at 10:06:07AM +0600, Alex Hacker wrote:
> Yes, the AR5416 and so on chips uses the same Athersos CMOS technology and
> same principle of RSSI/noise measurements.
Sorry, I mean AR52xx/AR5413 chips.

[ath9k-devel] More on signal and noise

[Eduard GV]

Understood, big thank you.

However, the noise floor shouldn't take only thermal noise into
account. Man-made noise could raise the noise floor more than 6dB in
the congested 2.4GHz band (in the 5GHz band it should be lower).

By the way, I join the popular demand for having access to CSI data!

>
> 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
>

[ath9k-devel] More on signal and noise

[Alex Hacker]

On Tue, May 17, 2011 at 05:04:49PM -0700, Eduard GV wrote:
> Understood, big thank you.
> 
> However, the noise floor shouldn't take only thermal noise into
> account. Man-made noise could raise the noise floor more than 6dB in
> the congested 2.4GHz band (in the 5GHz band it should be lower).
Yes, in Atheros' scheme it raise the NF and lowers RSSI values same manner.
External noise shouldn't affect absolute RSSI level but it does.

> By the way, I join the popular demand for having access to CSI data!
By muself I don't believe what BF can sufficiently advance link quality.
TxBF is implemented in AR9390 chip, but with only 3 antennas it can raise RSSI
by less then 4.5dB, this is not a revolution.

[ath9k-devel] More on signal and noise

[Adrian Chadd]

On 20 May 2011 12:20, Alex Hacker <hacker@epn.ru> wrote:
> On Tue, May 17, 2011 at 05:04:49PM -0700, Eduard GV wrote:
>> Understood, big thank you.
>>
>> However, the noise floor shouldn't take only thermal noise into
>> account. Man-made noise could raise the noise floor more than 6dB in
>> the congested 2.4GHz band (in the 5GHz band it should be lower).

> Yes, in Atheros' scheme it raise the NF and lowers RSSI values same manner.
> External noise shouldn't affect absolute RSSI level but it does.

Well, if the noise is constant, and RSSI is "relative" signal strength
indicator, why wouldn't it?



Adrian

[ath9k-devel] More on signal and noise

[Alex Hacker]

On Fri, May 20, 2011 at 12:46:12PM +0800, Adrian Chadd wrote:
> > Yes, in Atheros' scheme it raise the NF and lowers RSSI values same manner.
> > External noise shouldn't affect absolute RSSI level but it does.
> 
> Well, if the noise is constant, and RSSI is "relative" signal strength
> indicator, why wouldn't it?
It is depending on what the RSSI acronym means. :) I'd accustomed that it means
Receive Signal Strength Indicator. The madwifi (if I don't miss) never gives an
absolute RSSI so havn't such problems. Contrary in ath9k RSSI is absolute
power of signal on receiver antenna input which by definition can not depend
on noise floor. But due to noise floor measurement method used in baseband it
does.

> Adrian
Best wishes,
Alex.

[ath9k-devel] More on signal and noise

[MaYongsen]

Hello!

I notice that the "sample" in "/sys/kernel/debug/ieee80211/phy0/ath9k" report 
'ChNoise Chain privNF #Reading Readings' and 'rssi:- ctl0 ctl1 ctl2 ext0 ext1 
ext2' at the same time. Anybody can tell me what's the difference and Atheros 
calculate the rssi in ath9k?

Thanks!

[ath9k-devel] More on signal and noise

[Eduard GV]

Hi,

What I've learned so far from this thread is that rs_rssi (struct
ath_rx_status) is actually an SNR (not an RSSI), in dB.
What's not yet clear to me is how is this value obtained. My guess
from Alex's explanation is that it is the result of subtracting the
gain of the AGC during a short period of silence, from gain locked on
packet's preamble ... ?????

If SNR is computed during packet's preamble (which I presume should be
identical regardless of the modulation used for data), why for a given
tx power, I got a lower SNR when I use faster modulations? The
difference between MCS0 and MCS7 is about 6dB (same for MCS8 and
MCS15).


Please, someone shed light...


Thanks!

[ath9k-devel] More on signal and noise

[Daniel Halperin]

On Thu, Jun 9, 2011 at 3:46 PM, Eduard GV <eduardgv@gmail.com> wrote:
> Hi,
>
> What I've learned so far from this thread is that rs_rssi (struct
> ath_rx_status) is actually an SNR (not an RSSI), in dB.

RSSI has no clear definition. An SNR is a perfectly valid form of RSSI.

> If SNR is computed during packet's preamble (which I presume should be
> identical regardless of the modulation used for data), why for a given
> tx power, I got a lower SNR when I use faster modulations? The
> difference between MCS0 and MCS7 is about 6dB (same for MCS8 and
> MCS15).

The right way to handle this is almost certainly to dig into the
driver source code and print out information about per-MCS tx power,
including values read from the registers in real-time. It's a
combination of logic involving calibration parameters from the EEPROM,
regulatory limits, and other device-specific information.

Have you tried, at all, to learn on your own?

That said, your assumption that TX power will be independent of
modulation is likely to be faulty. Have you heard of "Peak-to-Average
Power Ratio"? It's not uncommon to reduce the maximum transmit power
limit for higher modulations; check out this datasheet for the
AR9160-based Ubiquiti SR-71A: http://www.ubnt.com/sr71a

Dan

[ath9k-devel] More on signal and noise

[syed]

hi,
I am facing problem where rs_rssi becomes less for 2.4Ghz band.

Other chips beside hear it correctly.

What can be possible problem.
 

[ath9k-devel] More on signal and noise

[Adrian Chadd]

Look at what the NF calibration values are doing over time. rs_rssi is
calculated agains tthe noise floor, it's not an absolute signal level.


-a


On 10 January 2014 02:00, syed <liamsyed@yahoo.com> wrote:
> hi,
> I am facing problem where rs_rssi becomes less for 2.4Ghz band.
>
> Other chips beside hear it correctly.
>
> What can be possible problem.
>
>
>
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel