[OpenWrt-Devel] ASUS-MAP-AC2200 Low 5G RSSI issue

Sam Samy to.swami1 at gmail.com
Wed May 15 20:02:03 PDT 2019


Hi Guys,

  I looked into the boarddata/cal/otp files and all look good for all
the radios and match the stock firmware. Only issue I saw was ASUS
variant name is not present in the board-2.bin for PCIe QCA9888. This,
I worked around by removing the variant name in device tree so that it
will pick the standard one which seem to have the correct board data
for QCA9888 anyway.

Even Marius build that he posted online when he brought this board up
seem to have the same RSSI issue. Its generally 20dB down from stock
firmware which will the reduce the coverage range significantly by
20-25 feet.

I am attaching the debug logs with ATH10K_DBG_BOOT logs which prints
the files loaded and other boot information for your perusal.

At this point I am not sure if the firmware is even reading the
board/cal/otp data that is downloaded. Since I don't have access to
firmware I don't know how to debug this further.


Thanks



On Tue, May 14, 2019 at 6:00 PM Sam Samy <to.swami1 at gmail.com> wrote:
>
> > Yes, the implemented method for reading the data is not correct for the
> > wave 2 cards (and maybe also other). You can try the attached hack. At
> > least this worked in 2017 when I've poked around in the stuff with
> > Christian Lamparter.
>
> Latest code already seem to be doing this.
>
> Thanks
>
> On Tue, May 14, 2019 at 1:33 AM Sven Eckelmann <sven at narfation.org> wrote:
> >
> > On Monday, 13 May 2019 22:58:00 CEST Sam Samy wrote:
> > >  I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> > > band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> > > (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> > > fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> > > pretty low on any 5Ghz channel I put it in.  In one feet range I see -60dB
> > > RSSI, where as the stock firmware that came with the AP gives an RSSI
> > > of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> > > for most part. The 2Ghz is working fine.
> >
> > It could be the boarddata which contains more than the targetpower and CTLs
> > (and thus not necessarily visible in tpc_stats). As first check, test whether
> > your board-2.bin has the md5sum 34c1e73e609a27eb9848fdc89cbc2be7 for
> > /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin. Also check that the correct
> > BDF (with the variant string is loaded). But this should only affect
> > the QCA4019 5GHz PHY because the QCA9886 boarddata is generated here using the
> > pre-cal data from art (unsure whether this is valid or not for this board and
> > bootup sequence).
> >
> > You can just check with the ath10k-bdencoder [0] from qca-swiss-army-knife
> > whether the board files from board-2.bin are the ones which also your stock
> > firmware is loading.
> >
> > The next big problem are filters in the rx/tx chains [1]. The ieee80211-freq-
> > limit in the DTS file should assist you and not allow you to chose the wrong
> > channel/frequency for a specific PHY. But maybe the author accidentally
> > switched the settings in the board and actually wanted the lower 5GHz channels
> > on the SoC 5GHz PHY and the the upper 5GHz channels on the PCIe card? This
> > would be at least worth a try.
> >
> > > What is the reg. domains 0x20 and 0x58 value points to?
> >
> > It is 20 (0x14) and not 0x20. Same for 58 (0x3a)
> >
> > Btw. the regd numbers from QCA can be checked in regd_common.h [2]. The
> > mapping in regDomainPairs is not necessarily correct because someone has to
> > take them from the newest proprietary driver and use them to update the ath*k
> > stuff.
> >
> > >   Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
> > > for both the 5Ghz radios even though the
> > > pre-cal-pci-0000:01:00.0.bin/pre-cal-ahb-a800000.wifi.bin is correct.
> >
> > Yes, the implemented method for reading the data is not correct for the
> > wave 2 cards (and maybe also other). You can try the attached hack. At
> > least this worked in 2017 when I've poked around in the stuff with
> > Christian Lamparter.
> >
> > Kind regards,
> >         Sven
> >
> > [0] https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
> > [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=41a86debe3c0a01e075e749d0bb1c6d631e35c32
> > [2] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/regd_common.h?id=5fad78689a9229d08ea11af53e48de3c2a845ea3#n29
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asus_openwrt.log
Type: application/octet-stream
Size: 54301 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190515/31238ab7/attachment-0001.obj>


More information about the openwrt-devel mailing list