ath9k: Problems with diversity on AR9330

ath9k: Problems with diversity on AR9330

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

Hey,

we have trouble with an AR9330 (Hornet) based AP. This device has 2 antennas, and is supposed to support diversity (2 RX, 1 TX). However, diversity is not really enabled because the "alternative" antenna is not considered as "good", because not enough frames are received. It seems that at 99% of the time, alt_rssi (read from rs->rs_rssi_ctl1) is invalid (set to ATH9K_RSSI_BAD, -128), while main_rssi (read from rs->rs_rssi_ctl0) usually has sane values.

We test by sending from a 1m distance (Laptop), and both antennas are connected, so the alternative antenna should usually get some sane frames too.

We have also tried to swap the antenna configuration of main and alt (LNA1 and LNA2), but only the alt_rssi will be invalid, and we then receive via the alternative antenna. We therefore think that the antenna wiring is not the problem.

We have also checked EEPROM values, which seem to be correct as well. FYI, register set after reading the EEPROM are:
AR_PHY_MC_GAIN_CTRL = 13EF0200
AR_PHY_CCK_DETECT = 803E6788

Any ideas/pointers/suggestions?

Thanks!
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

Hi Simon,

On Fri, Jul 6, 2012 at 6:20 PM, Simon Wunderlich
<simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> Hey,
>
> we have trouble with an AR9330 (Hornet) based AP. This device has 2 antennas, and is supposed to support diversity (2 RX, 1 TX). However, diversity is not really enabled because the "alternative" antenna is not considered as "good", because not enough frames are received. It seems that at 99% of the time, alt_rssi (read from rs->rs_rssi_ctl1) is invalid (set to ATH9K_RSSI_BAD, -128), while main_rssi (read from rs->rs_rssi_ctl0) usually has sane values.

its been some good amount of time i had taken/tested take a look at
this. actually Gabor Juhos added the support for AR9330.
seems AR9003 family chipsets can exhibit this behaviour. i quickly
checked with AR9285(AR9002) which seems to have a positive RSSI
regulary in ctl0/ctl1.
i also have a AR9485(AR9003 family) which might be similar to AR9330.
just checked with removing the antenna in chain0 seems to bring
positive values in rssi_ctl1.
I just also observer the chain0 is "preferred" unless the RSSI is so
poor in it so chain1 is taken.
Please check if this work out for your case too.
also please see the throughput difference with/without antenna
diversity with one antenna broken.

I will check out the proper technical reason for such a
preference/compare with AR9285 (or) if its a bug in the code itself.
thanks for looking into this feature!

>
> We test by sending from a 1m distance (Laptop), and both antennas are connected, so the alternative antenna should usually get some sane frames too.
>
> We have also tried to swap the antenna configuration of main and alt (LNA1 and LNA2), but only the alt_rssi will be invalid, and we then receive via the alternative antenna. We therefore think that the antenna wiring is not the problem.
>
> We have also checked EEPROM values, which seem to be correct as well. FYI, register set after reading the EEPROM are:
> AR_PHY_MC_GAIN_CTRL = 13EF0200
> AR_PHY_CCK_DETECT = 803E6788
>
> Any ideas/pointers/suggestions?
>
> Thanks!
>         Simon
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk/23yMACgkQrzg/fFk7axZ86wCg8A5QQH+H+8H8lMiqBeCpYIyN
> fhEAnjs+pcyM462tbkre2M342k8DEX0C
> =i53p
> -----END PGP SIGNATURE-----
>



-- 
thanks,
shafi

Re: ath9k: Problems with diversity on AR9330

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

On Friday 06 July 2012 19:32:41 Mohammed Shafi wrote:
> Hi Simon,
> 
> On Fri, Jul 6, 2012 at 6:20 PM, Simon Wunderlich
> 
> <simon.wunderlich@s2003.tu-chemnitz.de> wrote:
> > Hey,
> > 
> > we have trouble with an AR9330 (Hornet) based AP. This device has 2
> > antennas, and is supposed to support diversity (2 RX, 1 TX). However,
> > diversity is not really enabled because the "alternative" antenna is not
> > considered as "good", because not enough frames are received. It seems
> > that at 99% of the time, alt_rssi (read from rs->rs_rssi_ctl1) is invalid
> > (set to ATH9K_RSSI_BAD, -128), while main_rssi (read from
> > rs->rs_rssi_ctl0) usually has sane values.
> its been some good amount of time i had taken/tested take a look at
> this. actually Gabor Juhos added the support for AR9330.
> seems AR9003 family chipsets can exhibit this behaviour. i quickly
> checked with AR9285(AR9002) which seems to have a positive RSSI
> regulary in ctl0/ctl1.
> i also have a AR9485(AR9003 family) which might be similar to AR9330.
> just checked with removing the antenna in chain0 seems to bring
> positive values in rssi_ctl1.
> I just also observer the chain0 is "preferred" unless the RSSI is so
> poor in it so chain1 is taken.
> Please check if this work out for your case too.

Removing the antenna on chain0 doesn't change the alt_rssi value for us. We 
only noticed that frames with alt_rssi != -128 have  the value rx_ant_conf == 
1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1) when 
both/chain0-only are attached. Still most of the packets had alt_rssi == -128 
and we saw changes in curr_main_set and curr_alt_set (after lot of data was 
sent).

> also please see the throughput difference with/without antenna
> diversity with one antenna broken.

We (Simon and me) tried to play with the antennas and came to following 
results:

* Both attached: 45 Mibit/s
* chain0 attached: 45 Mibit/s
* chain1 attached: 15 seconds nearly nothing, after that 25 Mibit/s

> I will check out the proper technical reason for such a
> preference/compare with AR9285 (or) if its a bug in the code itself.
> thanks for looking into this feature!

Thanks

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ath9k: Problems with diversity on AR9330

[Sven Eckelmann]

[-- Attachment #1.1: Type: text/plain, Size: 1163 bytes --]

On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
[...]
> > I just also observer the chain0 is "preferred" unless the RSSI is so
> > poor in it so chain1 is taken.
> > Please check if this work out for your case too.
> 
> Removing the antenna on chain0 doesn't change the alt_rssi value for us. We
> only noticed that frames with alt_rssi != -128 have  the value rx_ant_conf
> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1) when
> both/chain0-only are attached. Still most of the packets had alt_rssi ==
> -128 and we saw changes in curr_main_set and curr_alt_set (after lot of
> data was sent).

Here are some logs. We added some debug printk before first check in 
ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can see a 
difference in the output after (a more or less long time) both antennas were 
unplugged. The output looks extreme different when at least one antenna is 
attached.

alt_ant_conf is calculated using 
"alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be wrong. 
curr_alt_set and curr_main_set come from div_ant_conf queried using 
ath9k_hw_antdiv_comb_conf_get.

Kind regards
	Sven

[-- Attachment #1.2: after_both_antennas_unplugged.txt.zip --]
[-- Type: application/zip, Size: 1355 bytes --]

[-- Attachment #1.3: at_least_one_antenna.txt.zip --]
[-- Type: application/zip, Size: 1297 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

Hi Sven,

On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <sven@narfation.org> wrote:
> On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
> [...]
>> > I just also observer the chain0 is "preferred" unless the RSSI is so
>> > poor in it so chain1 is taken.
>> > Please check if this work out for your case too.
>>
>> Removing the antenna on chain0 doesn't change the alt_rssi value for us. We
>> only noticed that frames with alt_rssi != -128 have  the value rx_ant_conf
>> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1) when
>> both/chain0-only are attached. Still most of the packets had alt_rssi ==
>> -128 and we saw changes in curr_main_set and curr_alt_set (after lot of
>> data was sent).
>
> Here are some logs. We added some debug printk before first check in
> ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can see a
> difference in the output after (a more or less long time) both antennas were
> unplugged. The output looks extreme different when at least one antenna is
> attached.

thanks, i saw the logs. i could do some analysis with AR9485/AR9285.
as you had said before
alt_rssi is -128 when one antenna is unplugged, while having both out
seems to bring some
+tive value for alt_rssi.

>
> alt_ant_conf is calculated using
> "alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be wrong.
> curr_alt_set and curr_main_set come from div_ant_conf queried using
> ath9k_hw_antdiv_comb_conf_get.

thanks i would check this out.  As the algorithm itself is bit
complex, i would just revisit
and check it out. If i remember correctly Fast antenna diversity was
working fine with AR9485.

>
> Kind regards
>         Sven



-- 
thanks,
shafi

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> Hi Sven,
>
> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <sven@narfation.org> wrote:
>> On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
>> [...]
>>> > I just also observer the chain0 is "preferred" unless the RSSI is so
>>> > poor in it so chain1 is taken.
>>> > Please check if this work out for your case too.
>>>
>>> Removing the antenna on chain0 doesn't change the alt_rssi value for us. We
>>> only noticed that frames with alt_rssi != -128 have  the value rx_ant_conf
>>> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1) when
>>> both/chain0-only are attached. Still most of the packets had alt_rssi ==
>>> -128 and we saw changes in curr_main_set and curr_alt_set (after lot of
>>> data was sent).
>>
>> Here are some logs. We added some debug printk before first check in
>> ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can see a
>> difference in the output after (a more or less long time) both antennas were
>> unplugged. The output looks extreme different when at least one antenna is
>> attached.
>
> thanks, i saw the logs. i could do some analysis with AR9485/AR9285.
> as you had said before
> alt_rssi is -128 when one antenna is unplugged, while having both out
> seems to bring some
> +tive value for alt_rssi.
>
>>
>> alt_ant_conf is calculated using
>> "alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be wrong.
>> curr_alt_set and curr_main_set come from div_ant_conf queried using
>> ath9k_hw_antdiv_comb_conf_get.
>
> thanks i would check this out.  As the algorithm itself is bit
> complex, i would just revisit
> and check it out. If i remember correctly Fast antenna diversity was
> working fine with AR9485.

further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems to be
 ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
 ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
will check it out whats the one bit difference in CCK_DETECT


>
>>
>> Kind regards
>>         Sven
>
>
>
> --
> thanks,
> shafi



-- 
thanks,
shafi

Re: [ath9k-devel] ath9k: Problems with diversity on AR9330

[Sunil Mehta]

Hi Shafi,

We are facing similar problems with configuring the LNA2 of AR9331 for
diversity. Even though we try to set the RXCHAINMASK = 0x03, on checking
the value, it keeps showing as 0x01.

We are currently using LSDK-9.2.0_U10.1020. It appears that some where the
value may be hardcoded to 0x01 in this Release.

Can you suggest how to solve this.

Regards,
Sunil.


On 7/7/12 3:44 PM, "Mohammed Shafi" <shafi.wireless@gmail.com> wrote:

>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <shafi.wireless@gmail.com>
>wrote:
>> Hi Sven,
>>
>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <sven@narfation.org>
>>wrote:
>>> On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
>>> [...]
>>>> > I just also observer the chain0 is "preferred" unless the RSSI is so
>>>> > poor in it so chain1 is taken.
>>>> > Please check if this work out for your case too.
>>>>
>>>> Removing the antenna on chain0 doesn't change the alt_rssi value for
>>>>us. We
>>>> only noticed that frames with alt_rssi != -128 have  the value
>>>>rx_ant_conf
>>>> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1)
>>>>when
>>>> both/chain0-only are attached. Still most of the packets had alt_rssi
>>>>==
>>>> -128 and we saw changes in curr_main_set and curr_alt_set (after lot
>>>>of
>>>> data was sent).
>>>
>>> Here are some logs. We added some debug printk before first check in
>>> ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can see
>>>a
>>> difference in the output after (a more or less long time) both
>>>antennas were
>>> unplugged. The output looks extreme different when at least one
>>>antenna is
>>> attached.
>>
>> thanks, i saw the logs. i could do some analysis with AR9485/AR9285.
>> as you had said before
>> alt_rssi is -128 when one antenna is unplugged, while having both out
>> seems to bring some
>> +tive value for alt_rssi.
>>
>>>
>>> alt_ant_conf is calculated using
>>> "alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be
>>>wrong.
>>> curr_alt_set and curr_main_set come from div_ant_conf queried using
>>> ath9k_hw_antdiv_comb_conf_get.
>>
>> thanks i would check this out.  As the algorithm itself is bit
>> complex, i would just revisit
>> and check it out. If i remember correctly Fast antenna diversity was
>> working fine with AR9485.
>
>further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems
>to be
> ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
> ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
>will check it out whats the one bit difference in CCK_DETECT
>
>
>>
>>>
>>> Kind regards
>>>         Sven
>>
>>
>>
>> --
>> thanks,
>> shafi
>
>
>
>-- 
>thanks,
>shafi
>_______________________________________________
>ath9k-devel mailing list
>ath9k-devel@lists.ath9k.org
>https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

Hi Sunil,

>
> We are facing similar problems with configuring the LNA2 of AR9331 for
> diversity. Even though we try to set the RXCHAINMASK = 0x03, on checking
> the value, it keeps showing as 0x01.

chainmask is indeed 1 and its correct

 (AR_SREV_9485(ah) || AR_SREV_9285(ah) || AR_SREV_9330(ah))
                chip_chainmask = 1;


>
> We are currently using LSDK-9.2.0_U10.1020. It appears that some where the
> value may be hardcoded to 0x01 in this Release.

some internal build ?

>
> Can you suggest how to solve this.
>
> Regards,
> Sunil.
>
>
> On 7/7/12 3:44 PM, "Mohammed Shafi" <shafi.wireless@gmail.com> wrote:
>
>>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <shafi.wireless@gmail.com>
>>wrote:
>>> Hi Sven,
>>>
>>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <sven@narfation.org>
>>>wrote:
>>>> On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
>>>> [...]
>>>>> > I just also observer the chain0 is "preferred" unless the RSSI is so
>>>>> > poor in it so chain1 is taken.
>>>>> > Please check if this work out for your case too.
>>>>>
>>>>> Removing the antenna on chain0 doesn't change the alt_rssi value for
>>>>>us. We
>>>>> only noticed that frames with alt_rssi != -128 have  the value
>>>>>rx_ant_conf
>>>>> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1)
>>>>>when
>>>>> both/chain0-only are attached. Still most of the packets had alt_rssi
>>>>>==
>>>>> -128 and we saw changes in curr_main_set and curr_alt_set (after lot
>>>>>of
>>>>> data was sent).
>>>>
>>>> Here are some logs. We added some debug printk before first check in
>>>> ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can see
>>>>a
>>>> difference in the output after (a more or less long time) both
>>>>antennas were
>>>> unplugged. The output looks extreme different when at least one
>>>>antenna is
>>>> attached.
>>>
>>> thanks, i saw the logs. i could do some analysis with AR9485/AR9285.
>>> as you had said before
>>> alt_rssi is -128 when one antenna is unplugged, while having both out
>>> seems to bring some
>>> +tive value for alt_rssi.
>>>
>>>>
>>>> alt_ant_conf is calculated using
>>>> "alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be
>>>>wrong.
>>>> curr_alt_set and curr_main_set come from div_ant_conf queried using
>>>> ath9k_hw_antdiv_comb_conf_get.
>>>
>>> thanks i would check this out.  As the algorithm itself is bit
>>> complex, i would just revisit
>>> and check it out. If i remember correctly Fast antenna diversity was
>>> working fine with AR9485.
>>
>>further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems
>>to be
>> ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
>> ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
>>will check it out whats the one bit difference in CCK_DETECT
>>
>>
>>>
>>>>
>>>> Kind regards
>>>>         Sven
>>>
>>>
>>>
>>> --
>>> thanks,
>>> shafi
>>
>>
>>
>>--
>>thanks,
>>shafi
>>_______________________________________________
>>ath9k-devel mailing list
>>ath9k-devel@lists.ath9k.org
>>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>



-- 
thanks,
shafi

Re: [ath9k-devel] ath9k: Problems with diversity on AR9330

[Sunil Mehta]

Hi Shafi,

LSDK is a Atheros Release which supports AR9331. We are adding
applications on this.

We are unsure of how to confirm if the second LNA is enabled. How can we
check if the signals on LNA2 are being processed.

In the calibration data we are setting LNA1+LNA2 as primary. Are there any
other settings we should do.

Regards,
Sunil.


On 7/7/12 4:06 PM, "Mohammed Shafi" <shafi.wireless@gmail.com> wrote:

>Hi Sunil,
>
>>
>> We are facing similar problems with configuring the LNA2 of AR9331 for
>> diversity. Even though we try to set the RXCHAINMASK = 0x03, on checking
>> the value, it keeps showing as 0x01.
>
>chainmask is indeed 1 and its correct
>
> (AR_SREV_9485(ah) || AR_SREV_9285(ah) || AR_SREV_9330(ah))
>                chip_chainmask = 1;
>
>
>>
>> We are currently using LSDK-9.2.0_U10.1020. It appears that some where
>>the
>> value may be hardcoded to 0x01 in this Release.
>
>some internal build ?
>
>>
>> Can you suggest how to solve this.
>>
>> Regards,
>> Sunil.
>>
>>
>> On 7/7/12 3:44 PM, "Mohammed Shafi" <shafi.wireless@gmail.com> wrote:
>>
>>>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi
>>><shafi.wireless@gmail.com>
>>>wrote:
>>>> Hi Sven,
>>>>
>>>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <sven@narfation.org>
>>>>wrote:
>>>>> On Friday 06 July 2012 17:13:42 Sven Eckelmann wrote:
>>>>> [...]
>>>>>> > I just also observer the chain0 is "preferred" unless the RSSI is
>>>>>>so
>>>>>> > poor in it so chain1 is taken.
>>>>>> > Please check if this work out for your case too.
>>>>>>
>>>>>> Removing the antenna on chain0 doesn't change the alt_rssi value for
>>>>>>us. We
>>>>>> only noticed that frames with alt_rssi != -128 have  the value
>>>>>>rx_ant_conf
>>>>>> == 1 (LNA2) when only chain1 is attached and rx_ant_conf == 2 (LNA1)
>>>>>>when
>>>>>> both/chain0-only are attached. Still most of the packets had
>>>>>>alt_rssi
>>>>>>==
>>>>>> -128 and we saw changes in curr_main_set and curr_alt_set (after lot
>>>>>>of
>>>>>> data was sent).
>>>>>
>>>>> Here are some logs. We added some debug printk before first check in
>>>>> ath_ant_comb_scan ("if (main_rssi > 0 && alt_rssi > 0) {"). We can
>>>>>see
>>>>>a
>>>>> difference in the output after (a more or less long time) both
>>>>>antennas were
>>>>> unplugged. The output looks extreme different when at least one
>>>>>antenna is
>>>>> attached.
>>>>
>>>> thanks, i saw the logs. i could do some analysis with AR9485/AR9285.
>>>> as you had said before
>>>> alt_rssi is -128 when one antenna is unplugged, while having both out
>>>> seems to bring some
>>>> +tive value for alt_rssi.
>>>>
>>>>>
>>>>> alt_ant_conf is calculated using
>>>>> "alt_ant_conf = (rs->rs_rssi_ctl[2]) & ATH_ANT_RX_MASK;" and could be
>>>>>wrong.
>>>>> curr_alt_set and curr_main_set come from div_ant_conf queried using
>>>>> ath9k_hw_antdiv_comb_conf_get.
>>>>
>>>> thanks i would check this out.  As the algorithm itself is bit
>>>> complex, i would just revisit
>>>> and check it out. If i remember correctly Fast antenna diversity was
>>>> working fine with AR9485.
>>>
>>>further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it
>>>seems
>>>to be
>>> ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
>>> ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
>>>will check it out whats the one bit difference in CCK_DETECT
>>>
>>>
>>>>
>>>>>
>>>>> Kind regards
>>>>>         Sven
>>>>
>>>>
>>>>
>>>> --
>>>> thanks,
>>>> shafi
>>>
>>>
>>>
>>>--
>>>thanks,
>>>shafi
>>>_______________________________________________
>>>ath9k-devel mailing list
>>>ath9k-devel@lists.ath9k.org
>>>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>
>
>
>-- 
>thanks,
>shafi

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

> further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems to be
>  ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
>  ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
> will check it out whats the one bit difference in CCK_DETECT

also could you provide the output of the attached patch, i would just
check the diversity
configuration


-- 
thanks,
shafi

[-- Attachment #2: div-eep-dump.patch --]
[-- Type: application/octet-stream, Size: 605 bytes --]

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 2cdf82b..5430384 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3631,6 +3631,8 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw *ah, bool is2ghz)
 
 	if (AR_SREV_9330(ah) || AR_SREV_9485(ah)) {
 		value = ath9k_hw_ar9300_get_eeprom(ah, EEP_ANT_DIV_CTL1);
+
+		printk("\nAntenna Diversity %s EEP_ANT_DIV_CTL1 %x", __func__, value);
 		/*
 		 * main_lnaconf, alt_lnaconf, main_tb, alt_tb
 		 * are the fields present

Re: ath9k: Problems with diversity on AR9330

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hey Shafi,

we had this checked out before, the EEPROM/EEP_ANT_DIV_CTL1 value is set to 000000c9,
so bit 6 and 7 are on (as checked in this function).

Cheers,
	Simon

On Sat, Jul 07, 2012 at 04:02:12PM +0530, Mohammed Shafi wrote:
> > further i check with the CCK/DETECT and MC_GAIN_CTRL in ar9485, it  seems to be
> >  ar9003_hw_ant_ctrl_apply CCK_DETECT 80be6788
> >  ar9003_hw_ant_ctrl_apply MC_GAIN_CTRLL 13ef0200
> > will check it out whats the one bit difference in CCK_DETECT
> 
> also could you provide the output of the attached patch, i would just
> check the diversity
> configuration
> 
> 
> -- 
> thanks,
> shafi



[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

Hey Simon,

> we had this checked out before, the EEPROM/EEP_ANT_DIV_CTL1 value is set to 000000c9,
> so bit 6 and 7 are on (as checked in this function).
>

this seems to match with the value AR9485. I am bit involved with some
other task which i need to finish
by some time. I will definitely get back to this once i am done with
that. Obviously i need to lot more
analysis and test in a shielded environment to get a grasp of this.
Further i can only ensure it in
AR9485.


-- 
thanks,
shafi

Re: ath9k: Problems with diversity on AR9330

[Mohammed Shafi]

>
>> we had this checked out before, the EEPROM/EEP_ANT_DIV_CTL1 value is set to 000000c9,
>> so bit 6 and 7 are on (as checked in this function).
>>

with inputs from Felix Bitterli,

-128 means: no measurement performed on this antenna.This will happen
with strong signals where too many gain-changes are needed to bring
the input signal into range, after which there is no time left to take
a measurement at the alternate antenna.

So:
1) to see diversity at work, increase the distance (dramatically).
2) There is no problem, the system is working correctly.

will provide some updates when i find some time to test.

-- 
thanks,
shafi