Open rodizio1 opened 7 years ago
hi,
The values have to do with the PHY behaviour and calibration behaviour. They're not exact dBm values.
It should always be -62dB for energy detect; that's programmed elsewhere.
I .. hm, this reminds me of some outstanding PHY questions. Lemme go ask.
-adrian
On 22 January 2017 at 07:35, Rodizio notifications@github.com wrote:
I noticed AR9287 cards seem to be much more "cautious" when injecting traffic, i.e. if they refuse to inject if there is some other (I think non-Wifi) signal present, while AR9271 cards only refuse to inject when there is a tranmitter nearby.
I found some reference in 802.11 standards to the thresholds being -82dbm for carrier sense (i.e. other wifi traffic) and -62dbm for energy detect (non-wifi signals).
My feeling is somehow, AR9287 cards also use the -82dbm value for non-wifi signals (?)
Looked through the drivers and found something in ar9002_phy.h:
define AR_PHY_CCA_NOM_VAL_5416_2GHZ -90
define AR_PHY_CCA_NOM_VAL_5416_5GHZ -100
define AR_PHY_CCA_MIN_GOOD_VAL_5416_2GHZ -100
define AR_PHY_CCA_MIN_GOOD_VAL_5416_5GHZ -110
define AR_PHY_CCA_MAX_GOOD_VAL_5416_2GHZ -80
define AR_PHY_CCA_MAX_GOOD_VAL_5416_5GHZ -90
define AR_PHY_CCA_NOM_VAL_9280_2GHZ -112
define AR_PHY_CCA_NOM_VAL_9280_5GHZ -112
define AR_PHY_CCA_MIN_GOOD_VAL_9280_2GHZ -127
define AR_PHY_CCA_MIN_GOOD_VAL_9280_5GHZ -122
define AR_PHY_CCA_MAX_GOOD_VAL_9280_2GHZ -97
define AR_PHY_CCA_MAX_GOOD_VAL_9280_5GHZ -102
define AR_PHY_CCA_NOM_VAL_9285_2GHZ -118
define AR_PHY_CCA_MIN_GOOD_VAL_9285_2GHZ -127
define AR_PHY_CCA_MAX_GOOD_VAL_9285_2GHZ -108
define AR_PHY_CCA_NOM_VAL_9271_2GHZ -118
define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ -127
define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ -116
define AR_PHY_CCA_NOM_VAL_9287_2GHZ -112
define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ -127
define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ -97
Ist this the right place to experiment with those values? Somehow they seem too low, are there offsets or are these half-db values maybe?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qca/open-ath9k-htc-firmware/issues/123, or mute the thread https://github.com/notifications/unsubscribe-auth/ABGl7UD_r7mElhXt6k1hgkeKH3xl2s6Iks5rU3degaJpZM4Lqagc .
Hiya,
ok. So, the TL;DR is:
Those min/max/good values aren't in dBm. There's no explicit absolute dBm value anywhere. Yes, a lot of drivers "lie". :-)
-adrian
Thanks. So this all is tied to the ANI functionality (which seems to be dynamic) and not just fixed values?
How can I further debug this? AR9287 cards become pretty much unusable as soon as there is some other faint signal around.
I noticed AR9287 cards seem to be much more "cautious" when injecting traffic, i.e. if they refuse to inject if there is some other (I think non-Wifi) signal present, while AR9271 cards only refuse to inject when there is a tranmitter nearby.
I found some reference in 802.11 standards to the thresholds being -82dbm for carrier sense (i.e. other wifi traffic) and -62dbm for energy detect (non-wifi signals).
My feeling is somehow, AR9287 cards also use the -82dbm value for non-wifi signals (?)
Looked through the drivers and found something in ar9002_phy.h:
Ist this the right place to experiment with those values? Somehow they seem too low, are there offsets or are these half-db values maybe?