WiFi, wcn3620, tx power much too low, cannot be changed

[welle]

We have developed an own embedded device based on the Open-Q™ 410 SOM (Snapdragon 410 processor).
The operating system is a Yocto Linux with a kernel based on qcomlt-4.9.56.

During the first uses in the field, a lack of WIFI range was found.
Measurements in the test lab showed that the TX power of the wcn3620 was only 9 dBm (channel 1) and 8.5 dBm (channel 6) instead of the expected 18-20 dBm.
Corresponding power measurements confirm this. During an iperf3 test, the current changed by only 60 mA, way too less for 20 dBm.

We also found that changing the TX power (via iw dev wlan0 set txpower fixed xxxx) does not result in any change in the transmission behavior.
Although iw dev displays the changed value, it has no effect.

As a next test, we set up an access point on the unit and measured its signal strength. Here, too, tying to change the TX power has no effect and the transmission field strength is too low.

A further test with an access point on a DragonBoard with the current image (dragonboard-410c-sdcard-installer-sid-1125.img) shows an analogue behavior: No possibility to influence the transmission field strength.

We urgently depend on a correctly functioning WIFI.

What could be the cause of this faulty behavior?
Can we do any additional work ourselves?

Many thanks in advance for the help!

[anon91830841]

hey,

what’s holding with with 4.9 based kernel (a 5 year old kernel)?

I don’t think anyone will be able to support such request on such an old kernel. The wifi driver used on the apq8016/DB410c has been drastically improved since 4.9, I am counting close to 200 patches just on this driver.

I would definitely recommend doing a major software upgrade at this point.

[welle]

As already written, the problem also exists in the current kernel/image.

We have tested snapshot 1125 from 20-Dec-2021, with kernel version 5.15.7.

Because you ask, an upgrade is planned, but any upgrade will require extensive (and expensive) driver certifications for us.

A solution for the current kernel should probably be enough for a backport.

[0xB0D]

How are you coming up with 8.5dbm ?

I have taken a db410c with a wcn3620 running 5.10.0-qcomlt-arm64 and connected it to an Asus RT-AX88U I’ve also taken an apq8039 with a wcn3680b running qualcomm’s 3.10 kernel and connected to the same AP.

The distance between the AP and both systems is roughly 20 centimeters.

The results are the following

The AP sees this

MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
db410c Yes Yes -24dBm n Yes Yes No No 1 20M 65M 6M 00:05:00
aqp8039 Yes Yes -17dBm n Yes Yes Yes No 1 20M 72.2M 6M 00:06:00

The DB410c sees the link as

root@linaro-developer:~# iw wlan0 link
Connected to 04:d4:c4:50:bb:58 (on wlan0)
SSID: nxsw-temp
freq: 2452
RX: 631320 bytes (3887 packets)
TX: 6709 bytes (79 packets)
signal: -27 dBm
rx bitrate: 72.2 MBit/s MCS 7 short GI
tx bitrate: 1.0 MBit/s
bss flags: short-slot-time
dtim period: 3
beacon int: 100

The aqp8039 sees the link as

console:/ # iw wlan0 link
Connected to 04:d4:c4:50:bb:58 (on wlan0)
SSID: nxsw-temp
freq: 2452
signal: -34 dBm
tx bitrate: 72.2 MBit/s MCS 7 short GI

How are you determining 8.5 dBm ? Do you have another device you can use as a control ?

[welle]

Thank you for the test.

The value 8.5 dBm was measured as transmission power in a test laboratory for emission measurements.

Unfortunately, this value cannot be derived directly from the RSSI value. Nevertheless, the comparison between DB410c and aqp8039 is interesting. The DB410c has a better reception quality (-27 dBm vs -34 dBm), but still a significantly worse transmission quality (-24 dBm vs -17 dBm).

[Loic]

Could you try disabling TX_PWR_CTRL_ENABLE in smd.c/wcn36xx_cfg_vals, just in case…

[welle]

In the last few days I have tested the two drivers (old and new) in a slightly different way.
Instead of measuring the signal strength on the receiver side, I measured the additional power consumption on the transmitter side.

According to the results I got, I think I was wrong and the current driver is transmitting at full power. I was misled by the analogue behaviour when setting the TX power. Sorry for the misinformation.

The reference to (TX_PWR_CTRL_ENABLE, 0) helped a lot with the investigation.

The comparison of the two drivers looks like this:
(first value: signal strength AP, second value: additional power consumption in mW).

Kernel 5.15.6, (TX_PWR_CTRL_ENABLE,1)
-25 dBm, 260 mW
-62 dBm, 430 mW

Kernel 5.15.6, (TX_PWR_CTRL_ENABLE,0)
-25 dBm, 490 mW
-59 dBm, 450 mW

Kernel 4.9.56, (TX_PWR_CTRL_ENABLE,1)
-32 dBm, 140 mW
-68 dBm, 300 mW

Kernel 4.9.56, (TX_PWR_CTRL_ENABLE,0)
-21 dBm, 370 mW
-62 dBm, 410 mW

Both drivers show similar behaviour, but the transmission power is significantly higher with the current kernel.

It would be helpful for me to know where in the driver the adjustment of the transmission power takes place.

[ljking]

1. The only correct way to get a valid power reading is with a RF power meter connected to the power measurement test jack on the board. The Jack (MM8030-2610B) is located close to the antenna. The mating connector is Murata “Measurement Probe for MM8030-2610 (P/N: MXHQ87WA3000)” this connector is somewhat expensive.

2. Your technique of measuring the received power at the Access Point is proportional, but subject to many errors. The radiation and reception patterns of the antennas on both the board and the router are not spherical, they are very irregular shaped. Rotating the board or the receiver even a few degrees in any axis will cause the readings to change by many dB. Did you move the board when you reinstalled the OS (say while plugging in the SDCard)?

3. Also keep in mind the driver is required by law to adjust transmit levels, and available channels based on which country it thinks it is in. When you setup Linux on the board ensure that it is setup in the same country.

4. Unfortunately measuring the DC power consumption on the board is meaningless when moving between versions of the kernel since the power consumption of the RF transmitter is swamped by the CPU cores. If the cores are running at different speeds this will throw off the readings significantly.

[welle]

The only correct way to get a valid power reading is with a RF power meter connected to the power measurement test jack on the board. The Jack (MM8030-2610B) is located close to the antenna. The mating connector is Murata “Measurement Probe for MM8030-2610 (P/N: MXHQ87WA3000)” this connector is somewhat expensive.

Thank you, that is valuable information. I’ll definitely pass that on to the hardware guys.

Your technique of measuring the received power is proportional, but subject to many errors. The radiation and reception patterns of the antennas on both the board and the router are not spherical, they are very irregular shaped. Rotating the board or the receiver even a few degrees in any axis will cause the readings to change by many dB. Did you move the board when you reinstalled the OS (say while plugging in the SDCard)?

I may have expressed myself wrongly. I am measuring the additional power consumption when sending.Our device is battery powered, via i2c the instantaneous voltage and the instantaneous current can be read out. The initial conditions are the same for all measurements. The distributions are created with Yocto on the same system and installed with fastboot on the same hardware. In parallel, I installed the distributions on a Dragonboard and measured them with current and voltage meters. The relations remain the same for both versions.

Also keep in mind the driver is required by law to adjust transmit levels, and available channels based on which country it thinks it is in. When you setup Linux on the board ensure that it is setup in the same country.

Of course. We are here in Germany
The device will then be intensively tested by a test laboratory.

Unfortunately measuring the DC power consumption on the board is meaningless when moving between versions of the kernel since the power consumption of the RF transmitter is swamped by the CPU cores. If the cores are running at different speeds this will throw off the readings significantly.

I have tried to exclude this as far as possible. It is always a relative measurement between stable system idle, send and back to idle. The distributions only run on the serial command line. No graphics, no peripherals, only the system and the WIFI.

[ljking]

@welle

(first value: signal strength AP, second value: additional power consumption in mW).

I was looking at the measurements you provided , and I discussed them in two separate paragraphs. The dBm readings are the “power” I was referring to in the second paragraph when I talked about received power. The dBm readings are wildly dependant on the physical locations and orientations of the transmitter and receiver. You probably want to fasten the router and the board to your desk with double sided foam tape so they can’t move. Also RF reflective surfaces like your laptop and monitor should be in fixed places.

In the fourth paragraph I was discussing the “additional power consumption” on the DC supply to the processor complex. You have done the best you can to control the variables, but keep in mind there are literally hundreds of autonomous system inside the 410c chip, and you have no control over what they are doing to power consumption (their goal is always to minimize power consumption, but to be ready so that the system is responsive).

For example there is a processor known as the “RPM” which monitors the bus activity of many of the internal subsystems. Having a main CPU execute even a single extra line of code can cause extra activity (example checking the state of TX_PWR_CTRL_ENABLE) on a bus, The RPM could decide to turn up the frequency or voltage of the that specific bus, or processor, in its belief that there is a higher load on the processor. Even worse there are internal subsystems that can turn themselves off/on, and slower/faster in response to almost any change in activity. In general all these things are probably not happening, but you can not control the autonomous systems and what they choose to do.

[ljking]

@0xB0D

The AP sees this

MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS BW Tx rate Rx rate Connect Time
db410c Yes Yes -24dBm n Yes Yes No No 1 20M 65M 6M 00:05:00
aqp8039 Yes Yes -17dBm n Yes Yes Yes No 1 20M 72.2M 6M 00:06:00

Going back in the thread a little further I see these RF power measurements. I suspect you can easily get a 7dB change (better or worse) by simply rotating either of the boards 30 degrees in any axis. Signal strength is not simply based on distance it is also affected by the shape of the antenna radiating pattern.

[0xB0D]

Fair point on the antenna.

The DB410c has one of those antenna embedded into the PCB the apq8039 has something alot better and yep, if I move the device [sic: both devices] around their respective axes the RSSI will change

[ljking]

https://jtl-engineering.com/antenna.html

This is a reasonably good image of the field strength. The Dragonboard antenna is an “Inverted F” configuration, so the radiation pattern (i.e. the RF signal strength in any given direction) should be similar to what is shown in the animation.