Asus map-ac2200 low transmit/receive signal 5Ghz

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 by a devolo 1750e:

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

Device: Asus Lyra map-ac2200

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:

OpenWRT ath10k 23dbm set

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

Stock 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

OpenWRT ath10k 26dbm set

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

Stock 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:

Stock 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

OpenWRT ath10k 20dbm set

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

Here are some receiving power comparisons. (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?

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.

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.

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).

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 Linksys EA6350v3 (civic) 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.

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.

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.