[ath9k-devel] Noise floor calibration causes 11 dB signal level swing

[Felix Fietkau <nbd@openwrt.org>]

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