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
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" <[email protected]> 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" <[email protected]> wrote:
>>
>>>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi
>>><[email protected]>
>>>wrote:
>>>> Hi Sven,
>>>>
>>>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <[email protected]>
>>>>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
>>>[email protected]
>>>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>
>
>
>--
>thanks,
>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
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
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
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" <[email protected]> wrote:
>
>>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <[email protected]>
>>wrote:
>>> Hi Sven,
>>>
>>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <[email protected]>
>>>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
>>[email protected]
>>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
--
thanks,
shafi
Hi Sven,
On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <[email protected]> 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
On Friday 06 July 2012 19:32:41 Mohammed Shafi wrote:
> Hi Simon,
>
> On Fri, Jul 6, 2012 at 6:20 PM, Simon Wunderlich
>
> <[email protected]> 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
Hi Simon,
On Fri, Jul 6, 2012 at 6:20 PM, Simon Wunderlich
<[email protected]> 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
On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <[email protected]> wrote:
> Hi Sven,
>
> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <[email protected]> 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
> 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
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" <[email protected]> wrote:
>On Sat, Jul 7, 2012 at 3:28 PM, Mohammed Shafi <[email protected]>
>wrote:
>> Hi Sven,
>>
>> On Fri, Jul 6, 2012 at 10:05 PM, Sven Eckelmann <[email protected]>
>>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
>[email protected]
>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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