try to find QCA9563 datasheet and see how to enable LNA/PA
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).
@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.
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.
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.
Is there an easy way to determine whether LNA is enabled?
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.
good catch for PA, regardless of LNA voltage it could still have some wrong set register distorting it's intended operation.
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.
i doubt it. try to put client device someplace it has -90dBm signal, then try repeating tests
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!
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.
If I can help with it I can start the discussion on the linux wireless list.
I requested help on Linux Wireless months ago but not too much interest. Do you have some progress on your side ? Thank you!
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.
I think that are two different things, QCA956x is WiSoC series (QCA9563 and QCA9561), the QCA/AR9565 is just a radio chip (old one).
Just tried with 19.07.0-rc2 and it seems it fixes the issue.
So sorry, the after upgrade the TX power set to 1000mW that is why I got better results.
sorry for reviving this old topic, but FYI, this was fixed last year with https://git.openwrt.org/?p=openwrt/openwrt.git;f=package/kernel/mac80211/patches/ath9k/580-ath9k_ar9561_fix_bias_level.patch;h=e4c2e1cd02cf0f1247b52b3f599e62942df4db0d and upstreamed at https://patchwork.kernel.org/project/linux-wireless/patch/20220417145145.1847-1-hacks+kernel@slashdirt.org/
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.