XD3200 (QCA9563) slow ath9k/2.4GHz - LNA/PA?

Installing and Using OpenWrt
1

I'm testing a Yuncore XD3200 in comparison to an UAP-AC-LITE, both running snapshot r3226-726e45d.
They have (nearly) identical hardware setup (QCA9563+QCA988x, 2 streams each), but the XD3200 has additional, external LNAs and PAs (SKY65174-21).
Both are running on channel 11, HT20, same txpower (10dBm) and same distance to the client (~2m)

While I'm only getting 18-22MBit (TCP, AP>Client) with the XD3200, the UAP-AC-LITE is stable at 38-45MBit, with the 'stock' XD3200 QSDK firmware and proprietary atheros driver I'm getting stable 39-41MBit.

Client readings (AP SNR):
XD3200: -53 dBm
XD3200 QSDK: -41dBm
UAP-AC-LITE: -37dBm

AP readings (Client SNR):
XD3200: -48 dBm / -95 dBm (SNR 47)
XD3200 QSDK: -34 dBm / -95 dBm (SNR 61)
UAP-AC-LITE: -37 dBm / -95 dBm (SNR 58)

Rate control seems to work without problems, while I see a bit more jitter they both end up at the highest MCS rate.

My guess would be that the onboard LNA/PA are not powered on, is there any way to verify this?

(update: redid the tests with 'stock' QSDK Firmware, results above)

2

your test is on a good way, still you miss stock XD3200 results under same conditions to know if it's LNA/PA problem

3

it has been a few days since i tested QSDK and didn't write down the results, I just redid the test, again same setup as r3226.
SNR seems to be pretty identical to UAP-AC-LITE apart from ~3db tolerance.

4

try to find QCA9563 datasheet and see how to enable LNA/PA

5

XD3200 doesn't have external LNAs for 2,4 GHz radio, only PAs (SKY65174-21).
As I can see, both PAs are always enabled (they are powered with 5V).

6

@pepe2k e.g. Chain0 Q11 looks for me suspiciously like an LNA+biasing network (L70,L71).

Have you got any idea what the signal+throuput degradation could be?

I'll see if can measure a difference in the PA analog reference levels between LEDE and QSDK with a DSO test probe.

7

I didn't know that, RF is not my main point of interests. I see that both the PAs and LNAs are connected to XPABIAS_x and XLNABIAS_x in QCA9563 SoC.

Maybe problem is in ath9k and/or related ART data parsing.

8

LNA usually have set eeprom value of about 13dB which corresponds differences in your test. recently i've found how to enable it on xiaomi mini and it improved the throughput. if you can find reference driver it could be of help.

9

Is there an easy way to determine whether LNA is enabled?

10

Ok, I did a few measurements on the LNA/PA supply and TX/RX switches with a DSO.

RX/TX switching seems to be fine, also LNA is getting ~3.3V when not transmitting and the PA is enabled at TX (although I did not measure if the chip is actulally transmitting at that time frame, I haven't got the equipment for that)

The difference I found between QSDK and ath9k/LEDE was:

  • QSDK is driving the PA with ~3.2V at R503/R823 (which results at ~3.0-3.1V at REF1/2)
  • ath9k (again snapshot r3226) is only supplying 2.8V, which results in ~2.6V at REF1/2, which is too low for the SKY65174-21 PA (2.75-3.1V).

So I guess the PA bias level seems to be incorrectly set.

11

good catch for PA, regardless of LNA voltage it could still have some wrong set register distorting it's intended operation.

12

so, sorry for the late update on this, I actually found the problem:

ath9k is setting the PA bias level for AR9561 AR_CH0_TOP2_XPABIASLVL instead of AR_CH0_TOP_XPABIASLVL (which is used for AR9565).

this patch resolves the problem for me:
https://github.com/oe1rfc/lede-qca9561-pa-bias/commit/88dcde

I'm not quite sure why there is a difference in ath9k between QCA9561 and QCA9565 or if this is just a problem of the XD3200 layout, I've neither got the QCA9561 datasheet nor XD3200 schematics.

It would be great if someone with ath9k-dev background could comment on this, otherwise I'll post it on linux-wireless.

btw: This doesn't change the RX or LNA levels, I guess the difference is actually a display error, since I can see no performance degradation and it seems to be hardwired to 3.3V / RX enable.

13

i doubt it. try to put client device someplace it has -90dBm signal, then try repeating tests

14

Thank you for sharing the patch it works well for me. Is this fixed in 17.01.3 or need to send a bug report?
Thank you!

15

no, this is not fixed in 17.01.3, this actually lies within the upstream ath9k code.

I'm still not sure if it's a problem of ath9k or if it's a problem of this particular device and the ath9k code handles QCA9561 and QCA9565 different for a reason. I haven't had time to start a discussion in linux-wireless, but it's on my ToDo list.

16

If I can help with it I can start the discussion on the linux wireless list.

17

I requested help on Linux Wireless months ago but not too much interest. Do you have some progress on your side ? Thank you!

18

Sorry, nothing new on this.

The question for me is, why is the TX Bias in ath9k differently set between QCA9565 and QCA9561? AFAIK the only difference between these chips are the internal ethernet switch in QCA9565.

19

I think that are two different things, QCA956x is WiSoC series (QCA9563 and QCA9561), the QCA/AR9565 is just a radio chip (old one).

20

Just tried with 19.07.0-rc2 and it seems it fixes the issue.