linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ath9k: noise floor calibration process
@ 2010-04-27 20:39 Benoit PAPILLAULT
  2010-04-28  0:01 ` [ath9k-devel] " RHS Linux User
  0 siblings, 1 reply; 5+ messages in thread
From: Benoit PAPILLAULT @ 2010-04-27 20:39 UTC (permalink / raw)
  To: ath9k-devel; +Cc: linux-wireless

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ath9k-devel] ath9k: noise floor calibration process
  2010-04-27 20:39 ath9k: noise floor calibration process Benoit PAPILLAULT
@ 2010-04-28  0:01 ` RHS Linux User
  2010-04-28  6:04   ` Benoit PAPILLAULT
  0 siblings, 1 reply; 5+ messages in thread
From: RHS Linux User @ 2010-04-28  0:01 UTC (permalink / raw)
  To: Benoit PAPILLAULT; +Cc: ath9k-devel, linux-wireless


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
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ath9k-devel] ath9k: noise floor calibration process
  2010-04-28  0:01 ` [ath9k-devel] " RHS Linux User
@ 2010-04-28  6:04   ` Benoit PAPILLAULT
  2010-04-28  9:24     ` RHS Linux User
  0 siblings, 1 reply; 5+ messages in thread
From: Benoit PAPILLAULT @ 2010-04-28  6:04 UTC (permalink / raw)
  To: RHS Linux User; +Cc: ath9k-devel, linux-wireless

RHS Linux User a écrit :
> 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.
>   
In fact, that's what I thought first, but according to Atheros patent, 
it can. It seems pretty logic in fact : if you have no real signal at 
the input, you are measuring ambient noise. A spectrum analyzer is able 
to do it as well.

Sensitivity is the ability to decode 802.11 modulation out of the signal 
received (which includes  any kind of noise). Using the formulas below, 
I measure the minimum signal levels of 802.11 packets by moving away 
from an AP and I indeed found -95dBm which is the typical sensitivity 
levels of an Atheros chip.
>    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 !
>   
Sure, in fact, I /think/ the thermal noise I'm talking is generated 
inside the first RX amplifier (it's probably generated in every RX 
amplifier, but the first is the biggest since it's amplified more than 
the others). So, if you put a low noise preamp, you are feeding the chip 
with more signal at the input but the chip has still the same amount of 
noise. Am I correct?
>    Have fun,
>
>    Wiz
>   
Regards,
Benoit
>
> 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
>>
>>     
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>   


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ath9k-devel] ath9k: noise floor calibration process
  2010-04-28  6:04   ` Benoit PAPILLAULT
@ 2010-04-28  9:24     ` RHS Linux User
  2010-04-28 12:53       ` Holger Schurig
  0 siblings, 1 reply; 5+ messages in thread
From: RHS Linux User @ 2010-04-28  9:24 UTC (permalink / raw)
  To: Benoit PAPILLAULT; +Cc: ath9k-devel, linux-wireless

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 8107 bytes --]


Hi Benoit,

   Yes. Having a patent is nice and probably significant too.

   However, if using a preamp with a low noise figure results in
more signals or stronger (more error free) signals, then it IS
better than the chip itself !!

   It is VERY surprising that no chips I am aware of provide directly for
support of an external low noise preamp AND on a seperate coax a REAL
amplifier.

   In the USA Amateur radio operators can use 1000 Watts (under certain
conditions) !!

   Now two high powered, low noise Acess Points with a clear line of sight
would give some real range!

   warm regards,
   Wiz


On Wed, 28 Apr 2010, Benoit PAPILLAULT wrote:

> RHS Linux User a écrit :
> > 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.
> >   
> In fact, that's what I thought first, but according to Atheros patent, 
> it can. It seems pretty logic in fact : if you have no real signal at 
> the input, you are measuring ambient noise. A spectrum analyzer is able 
> to do it as well.
> 
> Sensitivity is the ability to decode 802.11 modulation out of the signal 
> received (which includes  any kind of noise). Using the formulas below, 
> I measure the minimum signal levels of 802.11 packets by moving away 
> from an AP and I indeed found -95dBm which is the typical sensitivity 
> levels of an Atheros chip.
> >    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 !
> >   
> Sure, in fact, I /think/ the thermal noise I'm talking is generated 
> inside the first RX amplifier (it's probably generated in every RX 
> amplifier, but the first is the biggest since it's amplified more than 
> the others). So, if you put a low noise preamp, you are feeding the chip 
> with more signal at the input but the chip has still the same amount of 
> noise. Am I correct?
> >    Have fun,
> >
> >    Wiz
> >   
> Regards,
> Benoit
> >
> > 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
> >>
> >>     
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel@lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> >   
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ath9k-devel] ath9k: noise floor calibration process
  2010-04-28  9:24     ` RHS Linux User
@ 2010-04-28 12:53       ` Holger Schurig
  0 siblings, 0 replies; 5+ messages in thread
From: Holger Schurig @ 2010-04-28 12:53 UTC (permalink / raw)
  To: RHS Linux User; +Cc: Benoit PAPILLAULT, ath9k-devel, linux-wireless

>    In the USA Amateur radio operators can use 1000 Watts (under certain
> conditions) !!

Don't count on the 1000 W. Most countries have tight restrictions, only 
allowing certain frequencies, bandwiths, max PEP, max ERP, max EIRP, max 
electric field, max magnetic fields.

In Germany, with my license class, I can use up to 75W PEP in the frequency 
range 2320-2450 MHz. So, way less than 1000W. But I don't care, I wouldn't 
want to use 1000 W anyway. That's quite dangerous, e.g. if someone moves too 
near to the transmitting antenna.


> It is VERY surprising that no chips I am aware of provide directly for
> support of an external low noise preamp AND on a seperate coax a REAL
> amplifier.

However, as licensed ham radio op, I'm allowed to build and use self-build 
equipment. That means, I'm not restricted to use only certified devices, e.g. 
I don't need some FCC or ZZF or whatever number on my equipment. So I'm 
perfectly eligible to add some pre-amp. And guess what, for frequencies above 
100 MHz it's quite common to use low-noise pre-amps. Many HAMs do this, and 
also every satellite dish LNB does this.

I don't no chip "allowing" me this, I simply attach the pre-amp as near to the 
antenna as possible. How would a chip be able to prevent that anyway ?!?

Any WLAN chip provides for a separate coax. Again, how would a chip prevent 
against that?  Only some hybrid chip with built-in antenne could possible 
prevent me doing that. But maybe you don't mean chips, but devices?  Most USB 
dongles that I've seen won't provide a coax connector. But I have a bunch of 
PC-Card wlan cards with some SMA (or similar) coax connectors. And for Mini-
PCI cards it's the common case to provide some coax socket.


> Now two high powered, low noise Acess Points with a clear line of sight
> would give some real range!

Clear line of sight is nice, clear fresnel zone would be better.


Actually, what you're talking already happens already. It's called HAMNET.  
Some english language link that I found:

http://db0fhn.efi.fh-nuernberg.de/doku.php?id=projects:wlan:hamnet

Oh, and they use atheros hardware :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-04-28 12:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-27 20:39 ath9k: noise floor calibration process Benoit PAPILLAULT
2010-04-28  0:01 ` [ath9k-devel] " RHS Linux User
2010-04-28  6:04   ` Benoit PAPILLAULT
2010-04-28  9:24     ` RHS Linux User
2010-04-28 12:53       ` Holger Schurig

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