All of lore.kernel.org
 help / color / mirror / Atom feed
* [ath9k-devel] Noise floor calibration causes 11 dB signal level swing
@ 2012-02-06 17:12 Triangle Men
  2012-02-06 17:32 ` Felix Fietkau
  2012-02-06 19:12 ` Adrian Chadd
  0 siblings, 2 replies; 3+ messages in thread
From: Triangle Men @ 2012-02-06 17:12 UTC (permalink / raw)
  To: ath9k-devel


Hi,

I noticed the RSSI values in the receive status descriptor will occasionally drop 11 dB below expected, calculated, historical values and then stay in that range. Example: RSSI is in range {23,24} for a long time, then range drops to {12,13} for days. Last week I had a test setup doing this routinely within half a minute of initialization on channel 36, slightly less often on channel 48, and not at all on channel 149. I enabled ATH_DBG_CALIBRATE and found the 30-second interval noise floor calibration always precluded this change.

When there is a problem, I see that ath9k_hw_nf_sanitize prints "correcting to NOM." In this case the reported noise floor is below the pre-defined minimum AR_PHY_CCA_MIN_GOOD_VAL_9280_5GHZ (-122), so the driver decides to use a different value, AR_PHY_CCA_NOM_VAL_9280_5GHZ (-112.) The result is RSSI seems mis-calibrated by 11 dB, leading me to believe that -123 dB is the proper noise floor. (Though I don't understand the physics.) At any rate, all I know is the driver gets AR_PHY_CCA, AR_PHY_EXT_CCA, and so forth - I know not what these values may be. Is -122 a hardware limit? Does -123 represent an error? My calibrations are returning -121 and -122 right now, so if -123 or lower is valid, I may want to redefine AR_PHY_CCA_MIN_GOOD_VAL_9280_5GHZ. Can someone who knows more about the hardware shed some light on this?

Hardware: Ubiquity SR71-15 (AR9220), Ubiquity Routerstation.

Software: compat-wireless 4/19/11 fork with Linux-2.6.32.10.
The noise floor calibration code appears unchanged since that version. I can load a newer version to verify the problem still exists, but my setup is currently not exhibiting the problem.

Thanks

P.S. - I would still like very much to learn whether the hardware-generate block ACKs can be delayed to the next TXOP. (bump)
 		 	   		  

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

* [ath9k-devel] Noise floor calibration causes 11 dB signal level swing
  2012-02-06 17:12 [ath9k-devel] Noise floor calibration causes 11 dB signal level swing Triangle Men
@ 2012-02-06 17:32 ` Felix Fietkau
  2012-02-06 19:12 ` Adrian Chadd
  1 sibling, 0 replies; 3+ messages in thread
From: Felix Fietkau @ 2012-02-06 17:32 UTC (permalink / raw)
  To: ath9k-devel

On 2012-02-06 6:12 PM, Triangle Men wrote:
> 
> Hi,
> 
> I noticed the RSSI values in the receive status descriptor will occasionally drop 11 dB below expected, calculated, historical values and then stay in that range. Example: RSSI is in range {23,24} for a long time, then range drops to {12,13} for days. Last week I had a test setup doing this routinely within half a minute of initialization on channel 36, slightly less often on channel 48, and not at all on channel 149. I enabled ATH_DBG_CALIBRATE and found the 30-second interval noise floor calibration always precluded this change.
> 
> When there is a problem, I see that ath9k_hw_nf_sanitize prints "correcting to NOM." In this case the reported noise floor is below the pre-defined minimum AR_PHY_CCA_MIN_GOOD_VAL_9280_5GHZ (-122), so the driver decides to use a different value, AR_PHY_CCA_NOM_VAL_9280_5GHZ (-112.) The result is RSSI seems mis-calibrated by 11 dB, leading me to believe that -123 dB is the proper noise floor. (Though I don't understand the physics.) At any rate, all I know is the driver gets AR_PHY_CCA, AR_PHY_EXT_CCA, and so forth - I know not what these values may be. Is -122 a hardware limit? Does -123 represent an error? My calibrations are returning -121 and -122 right now, so if -123 or lower is valid, I may want to redefine AR_PHY_CCA_MIN_GOOD_VAL_9280_5GHZ. Can someone who knows more about the hardware shed some light on this?
> 
> Hardware: Ubiquity SR71-15 (AR9220), Ubiquity Routerstation.
> 
> Software: compat-wireless 4/19/11 fork with Linux-2.6.32.10.
> The noise floor calibration code appears unchanged since that version. I can load a newer version to verify the problem still exists, but my setup is currently not exhibiting the problem.
Noise floor calibration may be unchanged (I didn't check), but the
interpretation has changed. I added some code a while ago to translate
from the chip-specific internal noise floor to actual channel noise
values and use that for signal strength calculation.
Please try a recent version and see if it makes a difference. There are
also some useful stability fixes in there...

> P.S. - I would still like very much to learn whether the hardware-generate block ACKs can be delayed to the next TXOP. (bump)
Probably not.

- Felix

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

* [ath9k-devel] Noise floor calibration causes 11 dB signal level swing
  2012-02-06 17:12 [ath9k-devel] Noise floor calibration causes 11 dB signal level swing Triangle Men
  2012-02-06 17:32 ` Felix Fietkau
@ 2012-02-06 19:12 ` Adrian Chadd
  1 sibling, 0 replies; 3+ messages in thread
From: Adrian Chadd @ 2012-02-06 19:12 UTC (permalink / raw)
  To: ath9k-devel

Hi,

Just please keep in mind that the calibrated noise floor is a dB
value, it's not in relation to anything. You can't relate it (easily)
to an absolute dBm measurement.

So saying the noise floor is -123dB is not really saying it's below
thermal noise.


Adrian

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

end of thread, other threads:[~2012-02-06 19:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-06 17:12 [ath9k-devel] Noise floor calibration causes 11 dB signal level swing Triangle Men
2012-02-06 17:32 ` Felix Fietkau
2012-02-06 19:12 ` Adrian Chadd

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.