[Seine/ganges][pdx201/kirin] Android 10 SODP build has lower wifi levels comparing to stock

[AngryGami]

Platform: Seine Device: pdx201, kirin Kernel version: 4.14 Android version: 10 Software binaries version: SW_binaries_for_Xperia_Android_10.0.7.1_r1_v12b_seine.img, SW_binaries_for_Xperia_Android_10.0.7.1_r1_v12a_ganges.img

Description We had some issues with our phones keeping wifi connection up and decided to investigate what might be causing this. We measured wifi signal strength (at access point, i.e. how powerful signal phone produces) and compare various devices/rom versions and we have found following strangeness:

Model	Signal strength close to AP	Signal strength further away from AP	freq Band
Xperia 10 Mark 2 - Stock ROM	-41	-75	5GHz
Xperia 10 - Stock ROM	-46	-64	5GHz
Xperia 10 Mark 2 - AOSP	-57	-86	5GHz
Xperia 10 - AOSP	-54	-88	5GHz
Xperia 10 - Stock ROM	-49	--	2.4GHz
Xperia 10 - AOSP	-40	--	2.4GHz

For some reason SODP build of android having lower emitting power than stock device of same model. This must be some kind of configuration parameter probably but I can't find anything that might be related in source code. Lower signal level might affect wifi roaming (due to thresholds on APs) and now we have trouble with that as well (only on these models and Android 10 build).

Are there any ways to crank up wifi power for AOSP build?

[jerpelea]

Hello @AngryGami

The wireless configuration file is available on github and can be modified to match your needs https://github.com/sonyxperiadev/device-sony-seine/blob/master/rootdir/vendor/firmware/wlan/qca_cld/WCNSS_qcom_cfg.ini

The wireless driver is also available and can be modified to match your needs https://github.com/sonyxperiadev/vendor-qcom-opensource-wlan-qca-wifi-host-cmn https://github.com/sonyxperiadev/vendor-qcom-opensource-wlan-qcacld-3.0

[AngryGami]

I see that these repositories are part of kernel. In my build I rely on pre-built kernel. How can I control which driver will be included into my build?

[AngryGami]

I've also compared WCNSS_qcom_cfg.ini files from stock image and from AOSP image and they are 100% identical.

[jerpelea]

@AngryGami try to read the comments in the file and change the needed parameters

[AngryGami]

I've tried that - though they don't make a lot of sense to me. I can't tell which one might have desired effect. This file is identical on stock image and AOSP image and therefore I don't see any reason why changing anything there will fix my problem.

[jerpelea]

The values are identical with stock and will need local adjustments to match the desired expectation. For reference we will maintain the stock values on github.

[AngryGami]

Stock phones have higher level of signal with same parameters - doesn't this mean that problem is not in the parameters? Ok, you know better - maybe it is, though I have no idea which one I should tune to increase signal level - do you have any suggestions?

[jerpelea]

I am sorry but you will have to explore it yourself to match your needs

[jerpelea]

@AngryGami you can also try this patch but be careful as it is untested https://github.com/sonyxperiadev/kernel/pull/2384

[Haxk20]

@jerpelea Its quite a bump. We better wait until someone from us or you tests it. We dont want people testing such a huge bump in voltage.

[AngryGami]

So in theory, this could fry the device?

[Haxk20]

So in theory, this could fry the device?

In theory everything can fry the device. In reality it is unlikely this would fry it as we used this voltage before but i would not recommend testing it. I would recommend waiting until Konrad fixes his Pull Request (It isnt finished yet) and than wait for us to test it.

If one of us devs fry our device yea we screwed up and its on us. If you test it and something happens that would be super duper bad.

[AngryGami]

I can afford to fry up couple phones if need to :) Though I've tried this patch (rebuild kernel and rebuild image) and nothing changed in terms of wifi signal levels. I want to verify somehow that my kernel actually have these values set - is there any way to do that? Some log or kernel memory dump?

[jerpelea]

@AngryGami

check that the patch is in your kernel source kernel/sony/msm-4.14/kernel$ git log

build a new kernel blob remove from your tree kernel/sony/msm-4.14/common-kernel/dtbo kernel/sony/msm-4.14/common-kernel/kernel

and run build-kernels-clang.sh to rebuild the kernel

build a new android image with the new kernel remove old files rm /out/target/product//dtbo.img (if exists) rm /out/target/product//boot.img rm /out/target/product//kernel

build the new image source build/envsetup.sh lunch make bootimage

[MarijnS95]

@AngryGami Fyi you can also print the DT property from a running device:

akatsuki:/ # find /sys/firmware/ -iname *cx-mx-config -print -exec xxd -g4 {} \;
/sys/firmware/devicetree/base/soc/qcom,icnss@18800000/qcom,vdd-cx-mx-config
00000000: 000c3500 000c3500                    ..5...5.

Where 0xc3500 is 80000mV. For 848000mV you should see 000cf080 instead,

[AngryGami]

aosp-build:/aosp2/aosp10-build/kernel/sony/msm-4.14/kernel$ git diff arch/arm64/boot/dts/qcom/sdm630.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index c26a9ba7212b..162c78eeef16 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1600,7 +1600,7 @@
                vdd-1.8-xo-supply = <&pm660_l9_pin_ctrl>;
                vdd-1.3-rfa-supply = <&pm660_l6_pin_ctrl>;
                vdd-3.3-ch0-supply = <&pm660_l19_pin_ctrl>;
-               qcom,vdd-cx-mx-config = <525000 950000>;
+               qcom,vdd-cx-mx-config = <848000 848000>;
                qcom,vdd-1.8-xo-config = <1750000 1900000>;
                qcom,vdd-1.3-rfa-config = <1200000 1370000>;
                qcom,vdd-3.3-ch0-config = <3200000 3400000>;

pdx201:/ # find /sys/firmware/ -iname *cx-mx-config -print -exec xxd -g4 {} \;
/sys/firmware/devicetree/base/soc/qcom,icnss@C800000/qcom,vdd-cx-mx-config
00000000: 0009c400 0009c400                    ........

Wtf? :) I know that I'm not on the latest version of the patch, but as far as I can understand latest changes are more about narrowing to which devices these values will be applied, so this change to qcom,vdd-cx-mx-config should be there. Neither of values I got from my device matches values from previous source or new source... What this could mean? I've also compared these to my old image (with old kernel) - and they are identical to above (i.e. 00000000: 0009c400 0009c400)

[MarijnS95]

@AngryGami The PR only fixes it for SDM630/636, or Nile/Ganges as you also mentioned in the issue/title.

[AngryGami]

Aha... ok, then which file I need to change to make this work at pdx201?

[jerpelea]

@AngryGami grep for qcom,vdd-cx-mx-config

trinket.dtsi is for seine platform

[MarijnS95]

@AngryGami Seine is at 0.64V on both stock and SODP so that's likely not the issue here. Don't try bumping it to 0.8 :wink:

Instead, test this patch on Ganges.

[AngryGami]

I'll probably try both. Though it is strange that stock pdx201 has higher wifi signal as seen by AP even that as you say these voltages are same... how this is possible?

[Haxk20]

I'll probably try both. Though it is strange that stock pdx201 has higher wifi signal as seen by AP even that as you say these voltages are same... how this is possible?

On ganges the issue can be voltage. On Seine this is not the case and the issue is somewhere else. Thats how its possible.

[AngryGami]

Something else is tinkering with voltage or there is something that can affect wifi signal strength apart from voltage? (curious what this can be... at the end of the day emitted power should be proportional to voltage/current)

[Haxk20]

Something else is tinkering with voltage or there is something that can affect wifi signal strength apart from voltage? (curious what this can be... at the end of the day emitted power should be proportional to voltage/current)

Many things can affect the voltage but this is likely not the issue on seine. And a lot of things can affect wifi signal apart from voltage

[AngryGami]

And a lot of things can affect wifi signal apart from voltage

Could you think of an example? (I'm mean from inside software on the device - physical things like antenna configuration and or environment are not relevant)

[jerpelea]

there can be the power calculation (in the driver and HAL maybe an error) and configuration (in the ini file)

[jerpelea]

https://github.com/sonyxperiadev/device-sony-seine/blob/master/rootdir/vendor/firmware/wlan/qca_cld/WCNSS_qcom_cfg.ini#L305 please raise the value and check if it fixes your issue

[Haxk20]

Exactly what jerpelea said

[AngryGami]

@jerpelea I've tried to raise values of TxPower2g anb TxPower5g parameters to 20 and this seems to have no effect on transmit power of the phone.

[jerpelea]

@AngryGami did you try also raising the voltage ?

[AngryGami]

@jerpelea No, since @MarijnS95 said that this is unlikely the case for seine (stock has same values)

[jerpelea]

we will look at the WiFi driver in kernel to check if there is any omission there

[pablomh]

I've ported our local patches to both (LA.UM.9.1.r1 - A11 kumano) and (LA.UM.8.11.r1 - A10 seine) and I've seen similar results: ~15dBm difference.

[jerpelea]

@AngryGami I looked at how the power is set and it is dependent on the country The next step is to check if the country is properly set and passed to the kernel then check which power settings are passed

those are the stock profiles

country_list2=AR,BO,CL,EC,TF,PY,PE,PR,US,VE,CA,IN country_list3=DZ,AU,AT,BH,BE,BA,BR,BG,KH,CN,HR,CY,CZ,DK,EG,EE,FI,FR,DE,GR,GL,HK,HU,IS,ID,IE,IT,JO,KW,LV,LT,LU,MO,MY,MC,NL,NZ,NO,OM,PH,PL,PT,QA,RO,SA,RS,SG,SK,SI,ES,LK,SE,CH,TW,TH,TN,TR,AE,GB,UY,UZ,VN,YE,LI,MK,MT power=19,0,23,0,18,0 power2=19,0,23,0,21,0 power3=23,0,27,0,18,0

[AngryGami]

@jerpelea Thanks. Though these references you've made to some configuration file - where it is?

[jerpelea]

that configuration file is not used by AOSP. in your Sony image the wifi_txpower.conf file is located in vendor/etc/wifi

[AngryGami]

There is no such file on my device:

pdx201:/vendor/etc/wifi # ls -la
total 20
drwxr-xr-x  2 root shell 4096 2021-01-19 12:38 .
drwxr-xr-x 12 root shell 4096 2021-01-19 15:04 ..
-rw-r--r--  1 root root    67 2021-01-19 12:38 p2p_supplicant_overlay.conf
-rw-r--r--  1 root root    81 2021-01-19 12:38 wpa_supplicant.conf
-rw-r--r--  1 root root   148 2021-01-19 12:38 wpa_supplicant_overlay.conf

[MarijnS95]

You should be able to see all available frequencies with their power rating in iw phy0 info (or iw list, same thing). You can also read regulatory domain info:

130|pdx201:/ # iw reg get
global
country 00: DFS-UNSET
    (2402 - 2472 @ 40), (N/A, 20), (N/A)
    (2457 - 2482 @ 40), (N/A, 20), (N/A), PASSIVE-SCAN
    (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
    (5170 - 5250 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (5250 - 5330 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (5490 - 5710 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
    (57240 - 63720 @ 2160), (N/A, 0), (N/A)

phy#0 (self-managed)
country NL: DFS-ETSI
    (2402 - 2482 @ 40), (N/A, 20), (N/A)
    (5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR
    (5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS
    (5490 - 5730 @ 160), (N/A, 30), (0 ms), DFS
    (5735 - 5875 @ 80), (N/A, 14), (N/A)

[AngryGami]

Here what I've got:

pdx201:/ # iw reg get
global
country 00: DFS-UNSET
        (2402 - 2472 @ 40), (N/A, 20), (N/A)
        (2457 - 2482 @ 40), (N/A, 20), (N/A), PASSIVE-SCAN
        (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
        (5170 - 5250 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (5250 - 5330 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (5490 - 5710 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
        (57240 - 63720 @ 2160), (N/A, 0), (N/A)

phy#0 (self-managed)
country NO: DFS-ETSI
        (2402 - 2482 @ 40), (N/A, 20), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS
        (5490 - 5730 @ 160), (N/A, 30), (0 ms), DFS
        (5735 - 5875 @ 80), (N/A, 14), (N/A)

And honestly I have no idea what all of this mean :) List command spit out this:

pdx201:/ # iw list
Wiphy phy0
        max # scan SSIDs: 10
        max scan IEs length: 2048 bytes
        max # sched scan SSIDs: 16
        max # match sets: 16
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports roaming.
        Device supports T-DLS.
        Supported Ciphers:
                * WEP40 (00-0f-ac:1)
                * WEP104 (00-0f-ac:5)
                * TKIP (00-0f-ac:2)
                * 00-40-96:254
                * 00-40-96:255
                * CCMP (00-0f-ac:4)
                * WPI-SMS4 (00-14-72:1)
                * CMAC (00-0f-ac:6)
                * 00-0f-ac:11
                * 00-0f-ac:12
                * GCMP (00-0f-ac:8)
                * 00-0f-ac:9
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * monitor
                 * P2P-client
                 * P2P-GO
                 * Unknown mode (12)
        Band 1:
                Capabilities: 0x90f2
                        HT20/HT40
                        Static SM Power Save
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                        L-SIG TXOP protection
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT Max RX data rate: 150 Mbps
                HT TX/RX MCS rate indexes supported: 0-7
                VHT Capabilities (0x00000000):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                VHT RX MCS set:
                        1 streams: MCS 0-7
                        2 streams: MCS 0-7
                        3 streams: MCS 0-7
                        4 streams: MCS 0-7
                        5 streams: MCS 0-7
                        6 streams: MCS 0-7
                        7 streams: MCS 0-7
                        8 streams: MCS 0-7
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-7
                        2 streams: MCS 0-7
                        3 streams: MCS 0-7
                        4 streams: MCS 0-7
                        5 streams: MCS 0-7
                        6 streams: MCS 0-7
                        7 streams: MCS 0-7
                        8 streams: MCS 0-7
                VHT TX highest supported: 0 Mbps
                Bitrates (non-HT):
                        * 1.0 Mbps
                        * 2.0 Mbps
                        * 5.5 Mbps
                        * 11.0 Mbps
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 2412 MHz [1] (20.0 dBm)
                        * 2417 MHz [2] (20.0 dBm)
                        * 2422 MHz [3] (20.0 dBm)
                        * 2427 MHz [4] (20.0 dBm)
                        * 2432 MHz [5] (20.0 dBm)
                        * 2437 MHz [6] (20.0 dBm)
                        * 2442 MHz [7] (20.0 dBm)
                        * 2447 MHz [8] (20.0 dBm)
                        * 2452 MHz [9] (20.0 dBm)
                        * 2457 MHz [10] (20.0 dBm)
                        * 2462 MHz [11] (20.0 dBm)
                        * 2467 MHz [12] (20.0 dBm)
                        * 2472 MHz [13] (20.0 dBm)
                        * 2484 MHz [14] (disabled)
        Band 2:
                Capabilities: 0x90f2
                        HT20/HT40
                        Static SM Power Save
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                        L-SIG TXOP protection
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT Max RX data rate: 150 Mbps
                HT TX/RX MCS rate indexes supported: 0-7
                VHT Capabilities (0x039173b2):
                        Max MPDU length: 11454
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)
                        TX STBC
                        SU Beamformee
                        MU Beamformee
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 866 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 866 Mbps
                Bitrates (non-HT):
                        * 6.0 Mbps
                        * 9.0 Mbps
                        * 12.0 Mbps
                        * 18.0 Mbps
                        * 24.0 Mbps
                        * 36.0 Mbps
                        * 48.0 Mbps
                        * 54.0 Mbps
                Frequencies:
                        * 5180 MHz [36] (23.0 dBm) (no IR)
                        * 5200 MHz [40] (23.0 dBm) (no IR)
                        * 5220 MHz [44] (23.0 dBm) (no IR)
                        * 5240 MHz [48] (23.0 dBm) (no IR)
                        * 5260 MHz [52] (23.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5280 MHz [56] (23.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5300 MHz [60] (23.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5320 MHz [64] (23.0 dBm) (no IR, radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5500 MHz [100] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5520 MHz [104] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5540 MHz [108] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5560 MHz [112] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5580 MHz [116] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5600 MHz [120] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5620 MHz [124] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5640 MHz [128] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5660 MHz [132] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5680 MHz [136] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5700 MHz [140] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5720 MHz [144] (30.0 dBm) (radar detection)
                          DFS state: usable (for 144 sec)
                          DFS CAC time: 60000 ms
                        * 5745 MHz [149] (14.0 dBm) (no IR)
                        * 5765 MHz [153] (14.0 dBm) (no IR)
                        * 5785 MHz [157] (14.0 dBm) (no IR)
                        * 5805 MHz [161] (14.0 dBm) (no IR)
                        * 5825 MHz [165] (14.0 dBm) (no IR)
                        * 5845 MHz [169] (14.0 dBm) (no IR)
                        * 5865 MHz [173] (14.0 dBm) (no IR)
        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * start_ap
                 * new_station
                 * set_bss
                 * join_ibss
                 * set_pmksa
                 * del_pmksa
                 * flush_pmksa
                 * remain_on_channel
                 * frame
                 * frame_wait_cancel
                 * set_channel
                 * tdls_mgmt
                 * tdls_oper
                 * start_sched_scan
                 * testmode
                 * connect
                 * disconnect
                 * channel_switch
                 * Unknown command (122)
        Supported TX frame types:
                 * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
                 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
        Supported RX frame types:
                 * IBSS: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * managed: 0x40 0xb0 0xd0
                 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
                 * P2P-client: 0x40 0xd0
                 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
        WoWLAN support:
                 * wake up on anything (device continues operating normally)
                 * wake up on disconnect
                 * wake up on magic packet
                 * wake up on pattern match, up to 4 patterns of 6-64 bytes,
                   maximum packet offset 0 bytes
                 * can do GTK rekeying
                 * wake up on GTK rekey failure
                 * wake up on EAP identity request
                 * wake up on 4-way handshake
                 * wake up on rfkill release
        software interface modes (can always be added):
        valid interface combinations:
                 * #{ managed } <= 3,
                   total <= 3, #channels <= 2
                 * #{ managed } <= 1, #{ IBSS } <= 1,
                   total <= 2, #channels <= 2
                 * #{ AP } <= 3,
                   total <= 3, #channels <= 2
                 * #{ P2P-client } <= 1, #{ P2P-GO } <= 1,
                   total <= 2, #channels <= 2
                 * #{ managed } <= 2, #{ AP } <= 2,
                   total <= 4, #channels <= 2, STA/AP BI must match
                 * #{ managed } <= 2, #{ P2P-client, P2P-GO } <= 2,
                   total <= 4, #channels <= 2, STA/AP BI must match
                 * #{ managed } <= 2, #{ P2P-GO } <= 1, #{ AP } <= 1,
                   total <= 4, #channels <= 2, STA/AP BI must match
                 * #{ managed } <= 1, #{ P2P-client, P2P-GO } <= 1, #{ AP } <= 1,
                   total <= 3, #channels <= 2, STA/AP BI must match
                 * #{ managed } <= 1, #{ P2P-client, P2P-GO } <= 2,
                   total <= 3, #channels <= 2, STA/AP BI must match
                 * #{ monitor } <= 3,
                   total <= 3, #channels <= 2
        Device supports HT-IBSS.
        Device has client inactivity timer.
        Device accepts cell base station regulatory hints.
        Device supports SAE with AUTHENTICATE command
        Device supports scan flush.
        Device supports per-vif TX power setting
        Driver/device bandwidth changes during BSS lifetime (AP/GO mode)
        Device supports VHT-IBSS.

[AngryGami]

I found wifi_txpower.conf on my stock device, so should I add it to aosp build?

[MarijnS95]

Fyi starting a codeblock (that contains a console command with host:path $ command and the result) with: ```console gives it a nice highlight :slightly_smiling_face:

For starters, let's paste the full wifi_txpower.conf:

# WLAN Tx output power configuration
#
#  Format:
#   country_list=<comma-separated country list>
#   power=<2.4GHz_chain0_CCK>,<2.4GHz_chain1_CCK>,<2.4GHz_chain0_OFDM>,<2.4GHz_chain1_OFDM>,<5GHz_chain0_OFDM>,<5GHz_chain1_OFDM> in 1/2dBm
#  Power-Country_list table:
#   Power=country_list, power2=country_list2, power3=country_list3, power4= the others of country list, Power5=country_list3, Power6=All country
#
country_list=CF,CO,DO,IQ,JM,MA,NE,NG,SN,ZA,SY,KR,BY,IL,MX,RU,UA,00
country_list2=AR,BO,CL,EC,TF,PY,PE,PR,US,VE,CA,IN
country_list3=DZ,AU,AT,BH,BE,BA,BR,BG,KH,CN,HR,CY,CZ,DK,EG,EE,FI,FR,DE,GR,GL,HK,HU,IS,ID,IE,IT,JO,KW,LV,LT,LU,MO,MY,MC,NL,NZ,NO,OM,PH,PL,PT,QA,RO,SA,RS,SG,SK,SI,ES,LK,SE,CH,TW,TH,TN,TR,AE,GB,UY,UZ,VN,YE,LI,MK,MT
power=19,0,23,0,18,0
power2=19,0,23,0,21,0
power3=23,0,27,0,18,0
power4=31,0,35,0,34,0
power5=31,0,35,0,34,0
power6=0,0,0,0,0,0

Both our countries (NL/NO) are in country_list3. Apparently both power3= and power5= account for that...

We see 20dBm for 2.4GHz, 23dBm for 5GHz and 30dBm for 5GHz DFS. From the looks of it these are close enough to the values under 2.4GHz_chain0_CCK/2.4GHz_chain0_OFDM and 5GHz_chain0_OFDM in that file. By that logic, if power3 were used 2.4GHz TX goes up slightly, 5GHz down slightly. If power5 is used all go up drastically :thinking:. Can you extend the table in the original post with the frequencies this was tested on?

We really need a rooted stock device to run iw reg get on :wink:

[MarijnS95]

I found wifi_txpower.conf on my stock device, so should I add it to aosp build?

No, we don't have the service that supposedly reads this file and provides that as regulatory-domain info to the kernel/driver.

[MarijnS95]

Interestingly, the self-managed TX powers for phy0 match what the kernel reads from the regulatory db (global), and are about the same as what I see on a desktop with WiFi adapter:

global
country NL: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (5725 - 5875 @ 80), (N/A, 13), (N/A)
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

Maybe they are compensating for wrong/lowered physical transmit power?

[AngryGami]

@MarijnS95 So, do you have any idea what might be wrong with AOSP?

[MarijnS95]

@AngryGami We have some leads on transpower being potentially related, and are otherwise looking for the same dumps (iw list, iw reg get) on stock to compare what is going on.

Afaik stock applies the country - and likely this whole custom regulatory configuration pasted above - through some custom software, someone will need to dive in and confirm what it is doing exactly. At least self-managed indicates that the phy is able to report what regdom configuration is set, so that we can compare it.

[AngryGami]

@MarijnS95 Is there a way to test your assumption on AOSP? I mean, since stock reads this file and apply it to... driver (?) maybe we do similar stuff (even hardcoded for now) with AOSP?

[MarijnS95]

@AngryGami So we have the values from a stock Seine in China:

phy#0 (self-managed)
country CN: DFS-UNSET
    (2402 - 2482 @ 20), (N/A, 23), (N/A), AUTO-BW
    (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW, PASSIVE-SCAN
    (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
    (5735 - 5835 @ 80), (N/A, 30), (N/A), AUTO-BW, PASSIVE-SCAN

It is in the same country3 list as NL and NO, so you/me should likely see the same on stock.

While doing these tests can you check what frequency band it's on? Use iw wlan0 link and look at the freq: property. Perhaps it's in the low-power band (5735 - 5875 @ 80), (N/A, 14)?

[MarijnS95]

@MarijnS95 Is there a way to test your assumption on AOSP? I mean, since stock reads this file and apply it to... driver (?) maybe we do similar stuff (even hardcoded for now) with AOSP?

Perhaps see if these default values can be found in drivers/staging/wlan-qc - I currently lack the time to look, maybe tonight.

[AngryGami]

Nope, band seems to be in (5170 - 5250 @ 80) range:

pdx201:/ # iw wlan0 link
Connected to 70:6b:b9:97:63:af (on wlan0)
        SSID: ****
        freq: 5180
        RX: 29219 bytes (531 packets)
        TX: 14414 bytes (256 packets)
        signal: -71 dBm
        tx bitrate: 121.5 MBit/s VHT-MCS 6 40MHz VHT-NSS 1

[MarijnS95]

@AngryGami You can (should!) also hide earlier revisions in edit history :smile:

Newer iw can show txpower in iw wlan0 info. Fortunately I imported those into AOSP about a year ago when messing around with WiFi throughput testing: https://github.com/MarijnS95/iw

Can you check that branch out in external/iw, build it (m iw) and provide the value from both stock and SODP? I don't exactly know how representative it is, but it might give us more insight in what is actually going on. For good measure also collect iw reg get on stock as well.

EDIT: In addition, can you check compare the transmit power observed at the AP on 2.4GHz as well just so we know if it's affected?