Asus map-ac2200 low transmit/receive signal 5Ghz

Hardware Questions and Recommendations
1

Hey

I have around 15dbm lower transmit and received signal power when using OpenWRT instead of stock rom.
The APs are placed more or less at the same place.
Changing the Firmware to stock brings back the signal power expected. Changing Transmit Power is working as expected.
I tried ath10k-ct, changing the wlan country, comparing stock device-tree with OpenWRTs. Tried Openwrt 19.07 and Master.

For example the signal power received at channel 100 by a devolo 1750e from a map-ac2200 with:

Stock firmware: (Signal: -29 dBm) vs OpenWRT firmware: (Signal: -46 dBm)

Device:

Here are the scan results done with devolo.
One Asus Lyra is running with stock and the other one with openwrt.

root@OpenWrt-devolo:~# iwinfo wlan0 scan | grep  -A 3 10:7B:

Asus Lyra map-ac2200 with OpenWRT and ath10k 23dbm set

Cell 03 - Address: 10:7B:XX:XX:EF:8C
          ESSID: "Mywifi"
          Mode: Master  Channel: 36
          Signal: -56 dBm  Quality: 54/70

Asus Lyra map-ac2200 with Stock firmware @ 17dbm (read with iwconfig)

Cell 02 - Address: 10:7B:XX:XX:8F:AC
          ESSID: "Mywifi"
          Mode: Master  Channel: 36
          Signal: -45 dBm  Quality: 65/70

Asus Lyra map-ac2200 with OpenWRT and ath10k 26dbm set

Cell 06 - Address: 10:7B:XX:XX:EF:8A
          ESSID: "Mywifi"
          Mode: Master  Channel: 100
          Signal: -46 dBm  Quality: 64/70

Asus Lyra map-ac2200 with Stock firmware @ 26dbm auto (read with iwconfig)

Cell 09 - Address: 10:7B:XX:XX:8F:AA
          ESSID: "Mywifi"
          Mode: Master  Channel: 100
          Signal: -29 dBm  Quality: 70/70

In 2.4Ghz WIFI works as excepted.
2.4Ghz scan from another AP:

root@OpenWrt-devolo:~# iwinfo wlan1 scan | grep  -A 3 10:7B:

Asus Lyra map-ac2200 with OpenWRT and ath10k 20dbm set

Cell 13 - Address: 10:7B:XX:XX:EF:88
          ESSID: "Mywifi"
          Mode: Master  Channel: 11
          Signal: -35 dBm  Quality: 70/70

Asus Lyra map-ac2200 with with Stock firmware @ 16dbm (read with wificonfig)

Cell 04 - Address: 10:7B:XX:XX:8F:A8
          ESSID: "Mywifi"
          Mode: Master  Channel: 6
          Signal: -41 dBm  Quality: 69/70

Here are some receiving power comparisons.
e.g. power received from devolo AP at map-ac2200 (Stock: -50dBm vs OpenWRT: -66dBm)

10:7B:XX:XX:8F:AC______ Stock map-ac2200
10:7B:XX:XX:EF:8C______ OpenWRT map-ac2200
F4:06:XX:XX:38:95 ______ OpenWRT Devolo-1750E

This is the receiving power with OpenWRT:

root@OpenWrt-Lyra-One:~# iwinfo wlan0 scan | grep  -A 3 -B 1 "Mywifi"

Cell 02 - Address: 10:7B:XX:XX:8F:AC
          ESSID: "Mywifi"
          Mode: Master  Channel: 36
          Signal: -49 dBm  Quality: 61/70
          Encryption: WPA2 PSK (CCMP)
--
Cell 03 - Address: F4:06:XX:XX:38:95
          ESSID: "Mywifi"
          Mode: Master  Channel: 36
          Signal: -66 dBm  Quality: 44/70

This is the receiving power with Stock firmware:


Cell 02 - Address: 10:7B:XX:XX:EF:8C
          ESSID:"Mywifi"
          Mode:Master
          Frequency:5.18 GHz (Channel 36)
          Quality=94/94  Signal level=-48 dBm  Noise level=-95 dBm
...
		  
		  
Cell 03 - Address: F4:06:XX:XX:38:95
          ESSID:"Mywifi"
          Mode:Master
          Frequency:5.18 GHz (Channel 36)
          Quality=94/94  Signal level=-50 dBm  Noise level=-95 dBm
...

Wifi Power reading with Stock firmware with wificonfig


ath0      IEEE 802.11ng  ESSID:"Mywifi"
          Mode:Master  Frequency:2.437 GHz  Access Point: 10:7B:XX:XX:8F:A8
          Bit Rate:400 Mb/s   Tx-Power:16 dBm
          RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=94/94  Signal level=-97 dBm  Noise level=-95 dBm
          Rx invalid nwid:2887  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


ath1      IEEE 802.11ac  ESSID:"Mywifi"
          Mode:Master  Frequency:5.5 GHz  Access Point: 10:7B:XX:XX:8F:AA
          Bit Rate:866.7 Mb/s   Tx-Power:26 dBm
          RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=94/94  Signal level=-97 dBm  Noise level=-95 dBm
          Rx invalid nwid:282  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

ath2      IEEE 802.11ac  ESSID:"Mywifi"
          Mode:Master  Frequency:5.18 GHz  Access Point: 10:7B:XX:XX:8F:AC
          Bit Rate:866.7 Mb/s   Tx-Power:17 dBm
          RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=94/94  Signal level=-97 dBm  Noise level=-95 dBm
          Rx invalid nwid:398  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

What can be the reason?

@slh I have seen, you own the same device. Do you have the same problems?

2

Range, especially on the 5 GHz band, has never been great on my device, but I mostly blamed its internal antennas for that. Checking the pre-cal settings might help here.

3

Thanks for replying.

I am trying to examine the pre-cal file but dont know how. Tried a binary viewer to examine and [ath10k-bdencoder] to extract the data from pre-cal-ahb-a800000.wifi.bin
How would you check the calibration data?
Can I deactivate the use of pre-cal data? Tried to remove and replace them with empty files, which did not work.

IMO the range is pretty normal/good with 5Ghz using stock firmware and with 2.4Ghz for both OpenWRT and Stock.

4

I have not looked into the OEM firmware too much, but many other vendors ship multiple alternative pre-cal binaries with their firmware and load one of them. It might be that a wrong one was chosen for OpenWrt and submitted upstream to linux-firmware (see the tuning/ benchmarking for the ea6350v3).

A pre-cal file is necessary, but there might be a better one hiding in the OEM firmware (these files are model specific, not unique to each individual board, and are usually shipped in the OEM rootfs).

5

I have tried to make a new board-2.bin with boardData_2_0_QCA9888_5G_Y9484.bin and boardData_1_0_IPQ4019_DK04_5G.bin.

dmesg part form Stock:

ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=QCA9888/hw.2/boardData_2_0_QCA9888_5G_Y9484.bin

ol_transfer_bin_file: Board Data File download to address=0xc0000 file name=IPQ4019/hw.1/boardData_1_0_IPQ4019_DK04_5G.bin

dmesg part from OpenWRT:
[ 13.423837] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id 0:17 crc32 d94b5d72

[ 18.474359] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:21 crc32 e2dfaa91

I overwrite

bus=pci,bmi-chip-id=0,bmi-board-id=17.bin

with

boardData_2_0_QCA9888_5G_Y9484.bin

and rebuild board-2.bin with bdencoder for QCA9888. Replaced board-2.bin in /lib/firmware/ath10k/qca9888 with the new one.

I can’t see no real difference in signal strength.

For IPQ4019

bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=ASUS-MAP-AC2200.bin

has the same crc32 as

boardData_1_0_IPQ4019_DK04_5G.bin

Tried creating a new firmware-5.bin with the data from stock firmware.
./ath10k-fwencoder -c --otp otp.bin --firmware athwlan.bin --firmware-codeswap=athwlan.codeswap.bin --set-fw-api 5 --set-wmi-op-version 10.4 --set-htt-op-version 10.4

Did not change the signal strength.

I have read Optimized build for IPQ40xx devices but can't find any clue.

Did I do something wrong?
Could it be that the external PA is not activated? RFPA5542 should add around 20dBm.

6

Can the external power amplifier be driven by the regulator for SDHC?

I see sdhci activated in stock device tree but that makes no sense for a device without a memory slot.

		sdhci@7824000 {
			bus-width = <0x08>;
			cd-gpios = <0x51 0x16 0x01>;
			clock-names = "core iface";
			clocks = <0x02 0x2e 0x02 0x2d>;
			compatible = "qcom,sdhci-msm-v4";
			interrupts = <0x00 0x7b 0x00 0x00 0x8a 0x00>;
			pinctrl-0 = <0x53>;
			pinctrl-names = "default";
			reg = <0x7824900 0x11c 0x7824000 0x800>;
			sd-ldo-gpios = <0x51 0x21 0x01>;
			status = "ok";
			vqmmc-supply = <0x54>;
		};

		regulator@0 {
			compatible = "qcom,regulator-ipq40xx";
			linux,phandle = <0x54>;
			mask = <0x03>;
			phandle = <0x54>;
			reg = <0x1948000 0x04>;
			regulator-max-microvolt = <0x2dc6c0>;
			regulator-min-microvolt = <0x1b7740>;
			regulator-name = "SD0 VccQ";
			states = <0x2dc6c0 0x03 0x1b7740 0x01>;
		};

Those parts are missing in the dts for OpenWRT.

7

Nothing is impossible, but not necessarily - vendors usually start development with the DTS for the fullblown devboards and change only as little as possible to get their derived board working. As a consequence they often forget to remove devices they've cut out of their design. Alternatively sdhc support might have been part of their original design and was only dropped in later development stages, so this is something to try, but not necessarily a smoking gun.

8

I have found out the gpio 46-47 (maybe 44,45,48 too) is controlling the PA. Turning gpio on 47 to "out high" gave me a 20db boost on the qca9884 and ipq 5ghz wifi adapter. Turning both to "out high" did not increase the power on the QCA 9884 at all.

asus_map_ac2200
asus_map_ac22002424×1416 130 KB

setting gpio 46 to "out high" gave me a signal bump only to the ipq4019 wifi adapter

these are the gpio states from the stock rom

 gpio44  : out 0 2mA pull down
 gpio45  : out 0 2mA pull down
 gpio46  : out 0 2mA pull down
 gpio47  : out 0 2mA pull down
 gpio48  : out 0 2mA pull down
1 Like
9

Somehow this looks related:

10

Thanks. I will look into it tomorrow.

edit:

found the same file

		gpio_dir(39, GPIO_DIR_OUT);
		if ((nvram_match("wl0_country_code", "GB") && nvram_invmatch("territory_code", "EU/02") && nvram_invmatch("territory_code", "UK/02"))
		  || nvram_match("wl0_country_code", "CN"))
			set_gpio(39, 1);	// 3.3v: echo 1 > /sys/class/gpio/gpio39/value
		else
			set_gpio(39, 0);	// 5v  : echo 0 > /sys/class/gpio/gpio39/value

		/* set DPDT */
		gpio_dir(44, GPIO_DIR_OUT);
		set_gpio(44, 1);
		gpio_dir(45, GPIO_DIR_OUT);
		set_gpio(45, 0);
		gpio_dir(46, GPIO_DIR_OUT);
		set_gpio(46, 1);
		gpio_dir(47, GPIO_DIR_OUT);
		set_gpio(47, 0);

"release/src/router/rc/init.c"
in the source of the stock firmware "GPL_MAP-AC2200_3.0.0.4.384.46249-g97d05bb.tar"

1 Like
11

Yes, I just didn't find the OEM GPL tarball quickly (but I've now found https://dlcdnets.asus.com/pub/ASUS/wireless/Lyra/GPL_MAP_AC2200_300438446249.zip again), so I went searching beyond that.

12

This does in indeed seem to help massively, at least for the 5 GHz band (qca4019 and qca9984).

All defaults (voskhod):

a
a780×961 129 KB

root@lyra:~# cat /sys/class/gpio/gpiochip412/base 
412

#		/* 2.4G tx power switch */
#		gpio_dir(39, GPIO_DIR_OUT);
#		if ((nvram_match("wl0_country_code", "GB") && nvram_invmatch("territory_code", "EU/02") && nvram_invmatch("territory_code", "UK/02"))
#		  || nvram_match("wl0_country_code", "CN"))
#			set_gpio(39, 1);	// 3.3v: echo 1 > /sys/class/gpio/gpio39/value
#		else
#			set_gpio(39, 0);	// 5v  : echo 0 > /sys/class/gpio/gpio39/value
root@lyra:~# echo 451 >/sys/class/gpio/export 
root@lyra:~# echo out >/sys/class/gpio/gpio451/direction 
root@lyra:~# echo 0 >/sys/class/gpio/gpio451/value 

#		/* set DPDT */
#		gpio_dir(44, GPIO_DIR_OUT);
#		set_gpio(44, 1);
root@lyra:~# echo 456 >/sys/class/gpio/export 
root@lyra:~# echo out >/sys/class/gpio/gpio456/direction 
root@lyra:~# echo 1 >/sys/class/gpio/gpio456/value 

#		gpio_dir(45, GPIO_DIR_OUT);
#		set_gpio(45, 0);
root@lyra:~# echo 457 >/sys/class/gpio/export 
root@lyra:~# echo out >/sys/class/gpio/gpio457/direction 
root@lyra:~# echo 0 >/sys/class/gpio/gpio457/value 

#		gpio_dir(46, GPIO_DIR_OUT);
#		set_gpio(46, 1);
root@lyra:~# echo 458 >/sys/class/gpio/export 
root@lyra:~# echo out >/sys/class/gpio/gpio458/direction 
root@lyra:~# echo 1 >/sys/class/gpio/gpio458/value 

#		gpio_dir(47, GPIO_DIR_OUT);
#		set_gpio(47, 0);
root@lyra:~# echo 459 >/sys/class/gpio/export 
root@lyra:~# echo out >/sys/class/gpio/gpio459/direction 
root@lyra:~# echo 0 >/sys/class/gpio/gpio459/value

after (voskhod):

b
b780×958 134 KB

I'm not quite sure how to best express this in the DTS though.

13

Why did you used 456 for 44, 457 for 45, 458 for 46 and 459 for 47? Is it not simply the same number?

14

gpiochip base is 412, the offset (+the GPIO number).

Edit: To phrase it differently:

BASE_ADDR="$(cat /sys/class/gpio/gpiochip*/base | head -n1)"

#/* 2.4G tx power switch */
#gpio_dir(39, GPIO_DIR_OUT);
#if ((nvram_match("wl0_country_code", "GB") && nvram_invmatch("territory_code", "EU/02") && nvram_invmatch("territory_code", "UK/02"))
#  || nvram_match("wl0_country_code", "CN"))
#	set_gpio(39, 1);	// 3.3v: echo 1 > /sys/class/gpio/gpio39/value
#else
#	set_gpio(39, 0);	// 5v  : echo 0 > /sys/class/gpio/gpio39/value
echo "$(( ${BASE_ADDR} + 39 ))" >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 39 ))/direction
echo 0 >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 39 ))/value

#/* set DPDT */
#gpio_dir(44, GPIO_DIR_OUT);
#set_gpio(44, 1);
echo "$(( ${BASE_ADDR} + 44 ))" >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 44 ))/direction
echo 1 >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 44 ))/value

#gpio_dir(45, GPIO_DIR_OUT);
#set_gpio(45, 0);
echo "$(( ${BASE_ADDR} + 45 ))" >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 45 ))/direction
echo 0 >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 45 ))/value

#gpio_dir(46, GPIO_DIR_OUT);
#set_gpio(46, 1);
echo "$(( ${BASE_ADDR} + 46 ))" >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 46 ))/direction
echo 1 >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 46 ))/value

#gpio_dir(47, GPIO_DIR_OUT);
#set_gpio(47, 0);
echo "$(( ${BASE_ADDR} + 47 ))" >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 47 ))/direction
echo 0 >/sys/class/gpio/gpio$(( ${BASE_ADDR} + 47 ))/value
1 Like
15

Have created a pull request for the device tree. Touching only the gpios which affect the 5Ghz adapter.

2 Likes
16

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.