AR9271 antenna diversity issue #105

rodizio1 · 2016-10-08T16:41:01Z

Hello,

I've been testing quite a lot lately with Atheros wifi cards that use the ath9k_htc firmware.

As a background: These cards are used for a project that uses monitor mode and pcap packet injection to stream h264 video for FPV use (remote camera on a model plane). See here if interested in details: https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/

The setup works with two Raspberry Pi's, one on the aircraft, one on the ground:
Raspberry Pi camera --> raspivid application (fetches raw h264 from camera) --> tx application (injects packets via pcap) --> air --> rx application (receives packets in monitor mode) --> display application

I use TPLink WN722N sticks which use the Atheros AR9271 chipset. It has an RP-SMA antenna connector with a rubber-ducky antenna on it and also a small antenna printed on the PCB of the wifi stick.

According to this document: https://github.com/erikarn/ath9k-docs/blob/master/ath9k-hw-recv-single-chain-diversity.txt, the AR9271 has a switch in front of the chip, that somehow (I think I don't really understand the details ...) selects the "right" antenna (i.e. the one with the better signal) for reception.

However, I noticed some strange behaviour:

When being near the receiver, reception is good, packetloss is low, as expected
When being further away (so that RSSI is below roughly about -70dbm) quite a lot of packetloss appears, although the chipset can receive data succesfully down to around -84dBm (TX side sends 24Mbit 802.11g frames)
Now the strange part: When I cover the PCB antenna with my thumb and index finger, packetloss instantly stops and reception works pretty good again down to around -84dbm

At first, I didn't realize it was the switching (?), thought it was external interference or my hand causing reflections that make for a better signal (or whatever else strange RF-effect).

However, this problem seems reproducible. I've tried this at home as well as on an open field in the middle of nowhere, also on different frequencies. I also connected a coax extension to the RP-SMA output of the 722n stick and located the antenna 3 meters away so that covering the PCB antenna does not have any near-field effect on the rubber ducky. Still same problem.

Right now, my feeling is that the switching is not working correctly. I already searched on how to debug this, but I found infos only for the ath9k, not ath9k_htc driver.

Could somebody please shed some light into this, howto further debug?

Is it possible to disable the switching function in the driver by modifying something in antenna.c (so that only the external antenna is used) to see if I am on the right track?

Kernel used is 4.4.11 with ath9k_htc firmware version 1.4.

erikarn · 2016-10-08T18:05:09Z

hiya,

so the AR9271 is like an AR9285. It doesn't necessarily have an external
antenna switch - it can do something called "LNA mixing". Luckily, I went
and figured it all out a few years ago.

https://wiki.freebsd.org/dev/ath_hal%284%29/AntennaDiversity

and:

https://wiki.freebsd.org/dev/ath_hal%284%29/AntennaDiversityAR9285

Now, i don't know if all of the RX descriptor information is sent up in
ath9k_htc (and I really should write the freebsd version of this already so
I can experiment.) If it is, it'll be in the chain 2 primary/extension
channel RSSI fields, and you can decode them to see what's going on.

My guess is that the LNA mixing is not optimal for what you're doing and
its picking up some signal on that external LNA.

-adrian

On 8 October 2016 at 09:41, Rodizio notifications@github.com wrote:

Hello,

I've been testing quite a lot lately with Atheros wifi cards that use the
ath9k_htc firmware.

As a background: These cards are used for a project that uses monitor mode
and pcap packet injection to stream h264 video for FPV use (remote camera
on a model plane). See here if interested in details:
https://befinitiv.wordpress.com/wifibroadcast-analog-like-
transmission-of-live-video-data/

The setup works with two Raspberry Pi's, one on the aircraft, one on the
ground:
Raspberry Pi camera --> raspivid application (fetches raw h264 from
camera) --> tx application (injects packets via pcap) --> air --> rx
application (receives packets in monitor mode) --> display application

I use TPLink WN722N sticks which use the Atheros AR9271 chipset. It has an
RP-SMA antenna connector with a rubber-ducky antenna on it and also a small
antenna printed on the PCB of the wifi stick.

According to this document: https://github.com/erikarn/
ath9k-docs/blob/master/ath9k-hw-recv-single-chain-diversity.txt, the
AR9271 has a switch in front of the chip, that somehow (I think I don't
really understand the details ...) selects the "right" antenna (i.e. the
one with the better signal) for reception.

However, I noticed some strange behaviour:

When being near the receiver, reception is good, packetloss is low, as
expected

When being further away (so that RSSI is below roughly about -70dbm)
quite a lot of packetloss appears, although the chipset can receive data
succesfully down to around -84dBm (TX side sends 24Mbit 802.11g frames)

Now the strange part: When I cover the PCB antenna with my thumb and
index finger, packetloss instantly stops and reception works pretty good
again down to around -84dbm

At first, I didn't realize it was the switching (?), thought it was
external interference or my hand causing reflections that make for a better
signal (or whatever else strange RF-effect).

However, this problem seems reproducible. I've tried this at home as well
as on an open field in the middle of nowhere, also on different
frequencies. I also connected a coax extension to the RP-SMA output of the
722n stick and located the antenna 3 meters away so that covering the PCB
antenna does not have any near-field effect on the rubber ducky. Still same
problem.

Right now, my feeling is that the switching is not working correctly. I
already searched on how to debug this, but I found infos only for the
ath9k, not ath9k_htc driver.

Could somebody please shed some light into this, howto further debug?

Is it possible to disable the switching function in the driver by
modifying something in antenna.c (so that only the external antenna is
used) to see if I am on the right track?

Kernel used is 4.4.11 with ath9k_htc firmware version 1.4.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#105, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABGl7V_W26BzLGC0K9GowuTv_yEcJI3jks5qx8eegaJpZM4KRw-R
.

rodizio1 · 2016-10-09T21:05:35Z

I opened up a WN722N card, it indeed seems there are no active components "behind" the chip, so it must be doing LNA mixing like you say I guess.

In the link you posted:
"The ath(4) driver maps the RX LNA configuration used to the legacy "receive antenna" statistic. You can see this by compiling/running athstats."

Does this work with AR9271 USB cards under FreeBSD? Installing FreeBSD is no big deal, if this gives me some insight on which antenna is chosen under what circumstances, I'd try that.

Would de-soldering the white SMD component at the backside of the PCB be an option? This would cut the path to the PCB antenna. But not sure if this would make everything behave erratically ...

erikarn · 2016-10-09T21:58:40Z

There's no ath9k_htc support in freebsd yet. I keep wanting to do it but
keep finding other things to distract myself.

Maybe I'll finally go bring up the USB attach glue so i can prepare for
support.

As for ath9k support - it's not actually that hard to add the decoding
logic to the receive path. How good a C developer are you?

-a

On 9 October 2016 at 14:05, Rodizio notifications@github.com wrote:

I opened up a WN722N card, it indeed seems there are no active components
"behind" the chip, so it must be doing LNA mixing like you say I guess.

In the link you posted:
"The ath(4) driver maps the RX LNA configuration used to the legacy
"receive antenna" statistic. You can see this by compiling/running
athstats."

Does this work with AR9271 USB cards under FreeBSD? Installing FreeBSD is
no big deal, if this gives me some insight on which antenna is chosen under
what circumstances, I'd try that.

Would de-soldering the white SMD component at the backside of the PCB be
an option? This would cut the path to the PCB antenna. But not sure if this
would make everything behave erratically ...

[image: 722n]
https://cloud.githubusercontent.com/assets/21161270/19223583/85d11144-8e73-11e6-9e80-575ec144869e.jpg

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGl7RaMwwOusbUg768H4LNwliU4ZMw8ks5qyVcfgaJpZM4KRw-R
.

rodizio1 · 2016-10-09T22:15:49Z

Unfortunately, not a C developer at all.

I hoped it would be enough to add some printk's here and there to get an idea or add a reg_set[] ... line somewhere to disable the PCB antenna path.

erikarn · 2016-10-09T22:20:44Z

Let me take a stab at it next week. I have some ath9k_htc hardware around
here somewhere.

-a

On 9 October 2016 at 15:15, Rodizio notifications@github.com wrote:

Unfortunately, not a C developer at all.

I hoped it would be enough to add some printk's here and there to get an
idea or add a reg_set[] ... line somewhere to disable the PCB antenna path.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGl7flH5nB3amLKmDBn8XG6AFwLJkNHks5qyWeWgaJpZM4KRw-R
.

rodizio1 · 2016-11-20T10:51:33Z

Have done a lot more testing in the meantime with the white SMD component in the picture I posted above removed (so that the PCB antenna is disconnected).

This seems to have fixed the problem. Is there maybe a simple way to just disable the PCB antenna via software in the driver completely?

erikarn · 2016-11-21T18:35:17Z

Hi,

It needs to get some debugging added to ath9k. Soemone with ath9k_htc and
some free cycles should see if they can add antenna selection debugging
like there is for the AR9285 / AR9485.

-adrian

rodizio1 · 2017-01-27T11:59:20Z

Quoting you from the other thread:

If you have two antennas and one isn't working right then it's likely an antenna diversity or interference problem. If it's AR9271 then I can help someone who wants to do a bit of programming understand what's going on, as I know how antenna diversity works on AR9285/AR9485/AR9271.

Other users of my EZ-Wifibroadcast have now also disconnected the PCB antennas on their 722N sticks and also reported the issue is gone. So there is definitely something not right there.

from the AR9271 datasheet:

The AR9271 consists of two LNAs, denoted as LNA1 and LNA2. LNA2 is a dedicated Rx chain, while LNA1/Tx shares the Tx and Rx chains using an internal switch. Both LNA1 and LNA2 pass through an internal diversity combiner before being relayed on to the receiver. Four options exist for the combiner; LNA1, LNA2, LNA1-LNA2 and LNA1+LNA2. A software diversity algorithm determines which is used.

Unfortunately I cannot really help with coding (but I've succesfully managed to write to a register of the Atheros card, yay ;))

Maybe you can give me a hint on how to change those LNA settings or where to look in the code?
Then I could try different options to atleast narrow it down some.

olerem · 2017-01-27T15:15:02Z

@rodizio1 take a look at linux/drivers/net/wireless/ath/ath9k/eeprom_4k.c
LNA configurations seems to be there.

erikarn · 2017-01-27T16:10:01Z

Hi, It'd be good to know what the LNA configuration is for this NIC. CAn you cat base_eeprom from the ath9k/ debugfs directory?

…

-adrian

rodizio1 · 2017-01-30T00:27:17Z

Here is the output from base_eeprom and modal_eeprom:

       Minor Version :         13
            Checksum :      54331
              Length :        376
          RegDomain1 :      32924
          RegDomain2 :          0
             TX Mask :          1
             RX Mask :          1
          Allow 5GHz :          0
          Allow 2GHz :          1
   Disable 2GHz HT20 :          0
   Disable 2GHz HT40 :          0
   Disable 5Ghz HT20 :          0
   Disable 5Ghz HT40 :          0
          Big Endian :          0
   Cal Bin Major Ver :          0
   Cal Bin Minor Ver :          8
       Cal Bin Build :        109
        TX Gain type :          0

   2GHz modal Header :
 Chain0 Ant. Control :          0
 Ant. Common Control :  289674257
    Chain0 Ant. Gain :          0
       Switch Settle :         44
    Chain0 TxRxAtten :         32
   Chain0 RxTxMargin :          0
    ADC Desired size :        226
    PGA Desired size :          0
    Chain0 xlna Gain :         13
       txEndToXpaOff :          0
         txEndToRxOn :          2
      txFrameToXpaOn :         14
      CCA Threshold) :         28
 Chain0 NF Threshold :        186
             xpdGain :         12
         External PD :          1
Chain0 I Coefficient :          0
Chain0 Q Coefficient :          0
       pdGainOverlap :          6
    O/D Bias Version :          4
      CCK OutputBias :          5
     BPSK OutputBias :          4
     QPSK OutputBias :          4
    16QAM OutputBias :          0
    64QAM OutputBias :          0
    CCK Driver1_Bias :          4
   BPSK Driver1_Bias :          0
   QPSK Driver1_Bias :          0
  16QAM Driver1_Bias :          0
  64QAM Driver1_Bias :          0
    CCK Driver2_Bias :          4
   BPSK Driver2_Bias :          0
   QPSK Driver2_Bias :          0
  16QAM Driver2_Bias :          0
  64QAM Driver2_Bias :          0
      xPA Bias Level :          1
  txFrameToDataStart :         14
       txFrameToPaOn :         14
     HT40 Power Inc. :          0
     Chain0 bswAtten :          0
    Chain0 bswMargin :         31
  HT40 Switch Settle :         44
    Chain0 xatten2Db :          0
Chain0 xatten2Margin :          0
 Ant. Diversity ctl1 :         13
 Ant. Diversity ctl2 :          9
        TX Diversity :          0

bkil · 2017-03-20T00:41:20Z

A quick review points out that we would need to mask out the respective bits for diversity support (AR_PHY_CCK_DETECT_BB_ENABLE_ANT_FAST_DIV, AR_PHY_9285_ANT_DIV_CTL, etc) from antdiv_ctl1 and antdiv_ctl2 in ath9k_hw_4k_get_eeprom() and ath9k_hw_4k_set_board_values() of eeprom_4k.c as per the comments at the beginning of antenna.c.

Hopefully, masking of MAC_PCU_DEF_ANTENNA (AR_DEF_ANTENNA) will not be not necessary.

bkil · 2017-03-20T00:52:03Z

Ant. Diversity ctl1 : 13

bb_enable_ant_div_lnadiv : 1
bb_ant_div_alt_gaintb : 0
bb_ant_div_main_gaintb : 1
bb_enable_ant_fast_div : 1

Ant. Diversity ctl2 : 9

bb_ant_div_main_lnaconf = 10 (LNA1)
bb_ant_div_alt_lnaconf = 01 (LNA2)

erikarn · 2017-03-22T19:42:09Z

hiya, ok. So it's supposed to be enabling both antennas. You want to disable one, right? Just set the alt_lnaconf and main_lnaconf values to the same value, whichever you need (LNA1 or LNA2.) The permissable options are: LNA1 LNA2 LNA1+LNA2 LNA1-LNA2 .. the latter two are actually just straight signal mixing, no MIMO processing at all. It sounds like you don't need that at all; you just need LNA1 or LNA2 for both.

…

-adrian

On 19 March 2017 at 17:52, Thomas Nagy ***@***.***> wrote: Ant. Diversity ctl1 : 13 - bb_enable_ant_div_lnadiv : 1 - bb_ant_div_alt_gaintb : 0 - bb_ant_div_main_gaintb : 1 - bb_enable_ant_fast_div : 1 Ant. Diversity ctl2 : 9 - bb_ant_div_main_lnaconf = 10 (LNA1) - bb_ant_div_alt_lnaconf = 01 (LNA2) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGl7fcpcpevd7bqnRi2PIfqJy_IPvtGks5rnc20gaJpZM4KRw-R> .

rodizio1 · 2017-05-31T20:49:08Z

If I see it correctly in the AR9271 datasheet, the rx only chain (LNA2) has 3db better sensitivity.

3db higher link budget "for free" (i.e. without increasing txpower or using directional antennas) would be quite awesome. I think I'll try soldering an external antenna to that chain and change the code to use only LNA2.

Thanks a lot for your help guys.

bkil · 2017-06-01T00:39:28Z

Here are some further ideas if you'd like to gain some more free link budget without breaking regulations:

if, instead of transmitting G-only, you could somehow force N-only mode, unlocking enhanced features like short GI and frame aggregation would enable you to lower modulation rate for the same application throughput, getting a more robust link,
get a 2x2:2 MIMO stick on the aircraft, and broadcast in STBC to a commodity RX-STBC capable single chain receiver (it's a bit involved, but theoretically doable), (gives you +3dB),
if possible, get a kind of stick on both sides that can transmit in LDPC and force it on as well (could give you +1-3dB),
for reception, use as high MRC diversity order as possible, i.e., even 3 omni antenna 3x3 miniPCI cards can be found cheaply on online marketplaces (could give you ~2.5dB/extra antenna, given that it has good sensitivity)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AR9271 antenna diversity issue #105

AR9271 antenna diversity issue #105

rodizio1 commented Oct 8, 2016

erikarn commented Oct 8, 2016

When being near the receiver, reception is good, packetloss is low, as
expected

When being further away (so that RSSI is below roughly about -70dbm)
quite a lot of packetloss appears, although the chipset can receive data
succesfully down to around -84dBm (TX side sends 24Mbit 802.11g frames)

rodizio1 commented Oct 9, 2016

erikarn commented Oct 9, 2016

rodizio1 commented Oct 9, 2016

erikarn commented Oct 9, 2016

rodizio1 commented Nov 20, 2016

erikarn commented Nov 21, 2016

rodizio1 commented Jan 27, 2017

olerem commented Jan 27, 2017

erikarn commented Jan 27, 2017 via email

rodizio1 commented Jan 30, 2017

bkil commented Mar 20, 2017

bkil commented Mar 20, 2017

erikarn commented Mar 22, 2017 via email

rodizio1 commented May 31, 2017

bkil commented Jun 1, 2017

AR9271 antenna diversity issue #105

AR9271 antenna diversity issue #105

Comments

rodizio1 commented Oct 8, 2016

erikarn commented Oct 8, 2016

When being near the receiver, reception is good, packetloss is low, as expected

When being further away (so that RSSI is below roughly about -70dbm) quite a lot of packetloss appears, although the chipset can receive data succesfully down to around -84dBm (TX side sends 24Mbit 802.11g frames)

rodizio1 commented Oct 9, 2016

erikarn commented Oct 9, 2016

rodizio1 commented Oct 9, 2016

erikarn commented Oct 9, 2016

rodizio1 commented Nov 20, 2016

erikarn commented Nov 21, 2016

rodizio1 commented Jan 27, 2017

olerem commented Jan 27, 2017

erikarn commented Jan 27, 2017 via email

rodizio1 commented Jan 30, 2017

bkil commented Mar 20, 2017

bkil commented Mar 20, 2017

erikarn commented Mar 22, 2017 via email

rodizio1 commented May 31, 2017

bkil commented Jun 1, 2017

When being near the receiver, reception is good, packetloss is low, as
expected

When being further away (so that RSSI is below roughly about -70dbm)
quite a lot of packetloss appears, although the chipset can receive data
succesfully down to around -84dBm (TX side sends 24Mbit 802.11g frames)