you cannot use a board file from a factory firmware and copy it to board-2.bin. ath11k has a special header for the board files. so you need to process it with the ath11k swiss army knife tool first.
this patch does not cause any harm. i'm running it and in any way people would appreciate logs to check whats wrong on your side
1 Like
edit : im guessing board_id 255 is correct / ok. i took a look at the version that ships with openwrt on the 301w and yeah its board_id 255.
note, strictly for fun... i doubt i'll even be testing the board-2.bin that comes out 
so i've been able to figure out most of it... the only thing i dont quite understand is how to get the correct "board_id" and ultimatley does it even matter?
if i create a board-2.bin file with 1 board in it (the qca version has like 9... thats why its 1.3meg)... and the board_id does not match whatever board is loading the board-2.bin file, will the interfaces even come up?
or is it as simple as:
root@OPENWRT-UPSTAIRS:~# dmesg | grep board
[ 18.796924] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[ 19.336730] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
"...theres your board id..."?
fyi, as a backwards way of going at it i've essentaily:
a) run the board-2 (1.3 meg one) off qca through the extractor
b) presto, we now know what the json syntax looks like
c) with that, create a json + use the board file from the oem firmware and output board-2 using the qca tool.
d) board-2.bin ready to go!
edit : based on what @BrainSlayer said below, try at your own risk
i'm not sure if it will work or not, but try this:
i created this using the method outlined 1 post up.
its the bdwlan.bin from the oem firmware but in what should be the correct board-2.bin format.
there is no correct board_id. its always a bullshit id. so you have to specify a variant from your knowledge in dts. and this must be also the variant name in the board-2 file. if the variant in dts is missing or a a incorrect board file is referenced from board-2.bin any bad thing may happen. if you run a 5 ghz phy in 2.4 ghz or vice vesa for example. you will find out why devices are always driven by smoke. only if smoke comes out they are broken and this may happen then
understood.
i have not tested it, i will though once they are all asleep here... but i think the bdf i pulled from the oem firmware is correct.
although after going through all of this, i think the best and safest way forward would be:
a) copy over the board-2.bin that openwrt installs by deafult, so no 160mhz
b) unroll it using the qca swiss army tool
c) inject the 160mhz capabs using the script below
d) roll back up using the qca swiss army tool
e) install into openwrt
f) at this point we should have the same bdf that openwrt installs by default BUT with 160mhz enabled.
warning, i had gpt snap this together and made some changes... it seams to work though. the phy0/1/2 match up: on the nbg7815 0 = 5, 1 = 2.4, 2 = 5. note no detection of vht80 on phy1 (t
here is the output:
2024-08-06 20:32:36,075 - INFO - Reading file: 255.bin
2024-08-06 20:32:36,076 - INFO - Doing offset 1040
2024-08-06 20:32:36,076 - INFO - Current flags at offset 1040: 0x00001d55
2024-08-06 20:32:36,076 - INFO - VHT80 capability found at offset 1040
2024-08-06 20:32:36,076 - INFO - No need to add VHT80-80 as its already there
2024-08-06 20:32:36,076 - INFO - No need to add VHT160 as its already there
2024-08-06 20:32:36,076 - INFO - Doing offset 1280
2024-08-06 20:32:36,077 - INFO - Current flags at offset 1280: 0x00000000
2024-08-06 20:32:36,077 - INFO - No VHT80 capability at offset 1280, skipping
2024-08-06 20:32:36,077 - INFO - Doing offset 1376
2024-08-06 20:32:36,077 - INFO - Current flags at offset 1376: 0x00001d55
2024-08-06 20:32:36,077 - INFO - VHT80 capability found at offset 1376
2024-08-06 20:32:36,077 - INFO - No need to add VHT80-80 as its already there
2024-08-06 20:32:36,077 - INFO - No need to add VHT160 as its already there
2024-08-06 20:32:36,078 - INFO - Completed modification for file: 255.bin
here is the blob that gpt output that looks to do the trick, write is commented out so you need to re-enable to actually write the changes.
import struct
import logging
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
def read_file(file_path):
logging.info(f'Reading file: {file_path}')
with open(file_path, 'rb') as f:
data=f.read()
return data
def write_file(file_path,data):
logging.info(f'Writing file: {file_path}')
with open(file_path, 'wb') as f:
f.write(data)
def modify_flags(data,offsets):
for offset in offsets:
logging.info(f'Doing offset {offset}')
phy_flags=struct.unpack_from('<I',data,offset)[0]
logging.info(f'Current flags at offset {offset}: {phy_flags:#010x}')
if phy_flags&0x400: # Check if VHT80 capable
logging.info(f'VHT80 capability found at offset {offset}')
if not phy_flags&0x800: # Check if VHT80+80 capable
logging.info(f'Adding VHT80+80 capability at offset {offset}')
phy_flags|=0x800
else:
logging.info(f'No need to add VHT80-80 as its already there')
if not phy_flags&0x1000: # Check if VHT160 capable
logging.info(f'Adding VHT160 capability at offset {offset}')
phy_flags|=0x1000
else:
logging.info(f'No need to add VHT160 as its already there')
data=bytearray(data)
struct.pack_into('<I',data,offset,phy_flags)
else:
logging.info(f'No VHT80 capability at offset {offset}, skipping')
return data
def enable_vht160(file_path,offsets=[1040,1280,1376]):
data=read_file(file_path)
modified_data=modify_flags(data,offsets)
# write_file(file_path,modified_data)
logging.info(f'Completed modification for file: {file_path}')
bdf_path='255.bin'
enable_vht160(bdf_path)
from what i can say. i dont know any device with 3 radios which is vht160 capable. only the 2 radio devices are. the concept of this chip is that the antenna array is shared between the radios and this might be the reason why vht160 isnt possible on 3 radio devices. the example here in the comments where vht160 was working also showed the symtom that the third radio was missing.
1 Like
mmh i was reading the zyxel product page. i found no evidence that this device has 3 radios. from what i read it has just 2 radios and the vendor webinterface also allows just to configure 2 radios
2 Likes
- Transmit:
- 1200Mbps* for 2.4 GHz
- 4800Mbps* for 5 GHz
- Receive:
- 1200Mbps* for 2.4 GHz
- 4800Mbps* for 5 GHz
you are right, if it was dual 5ghz they would list double that?
i have it sitting right next to me now. ill get the stock owrt board-2 on there where phy0 - phy2 pop up and we'll see.
yeah its got 3 radios.
also, none of my cooked board files worked... i mean, they booted and even brought up phy0 + phy1, but 160mhz never worked.
what did / does continue to work is using the board-2 from qca, the 1.3meg one with the multiple bdf files. that one phy0 and phy1 come up, and phy0 can do 160mhz. no phy2 to be seen tho 
when i say can do 160mhz i mean actually can, my samsung connects at 160mhz 2400/2400.
anyways, that was fun... learnt a few new nuggets today. get qosmio build on here, get extroot up and running and you got yourself another capable ipq807x device. its even got bluetooth to boot!
...back to our regular programming.
btw this below is just for reference, iw dev lists 3 phys.
yes but you are just saying the same. 3 radios no vht160. 2 radios vht160. this makes also sense from the hw side and how the chipset works. now if you look in the usermanual of the original firmware you wont even find a third radio configuration but just 2 radios. same for the datasheet on the zyxel site
yeah i agree.
i will add this though, they list it as 4800/4800 @ 5ghz.
the image below shows 3 radios, each getting 4 antenna. id probably guess that its 2 x 2400/2400.
i'm putting it away for now, i had it running for 1 hour here while playing and was reminded how extremely hot it runs. even with no load the fan ramped up to any annoying level where you probably wouldn't want to have this in a room where people sleep... yeah, its got a fan. and rgb!
Yep, I did not test any of your bdf files, but a couple of hours ago I "updated" qca board file to newest 2.9.01 - just the big one from git page and it works as well.
My assumption then is that it doesn't have to be older file, just a 'full' one.
What would be a chances of it being one, powerful 5ghz radio? And I mean 8x8 one. Just a theory though?
Here is my iw phy with 'big' bdf file:
root@OpenWrt:~# iw phy phy0 info
Wiphy phy0
wiphy index: 0
max # scan SSIDs: 16
max scan IEs length: 142 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Available Antennas: TX 0xff RX 0xff
Configured Antennas: TX 0xff RX 0xff
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 2:
Capabilities: 0x19e7
RX LDPC
HT20/HT40
Dynamic SM Power Save
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: No restriction (0x00)
HT TX/RX MCS rate indexes supported: 0-63
VHT Capabilities (0x339ff9f6):
Max MPDU length: 11454
Supported Channel Width: 160 MHz
RX LDPC
short GI (80 MHz)
short GI (160/80+80 MHz)
TX STBC
SU Beamformer
SU Beamformee
MU Beamformer
MU Beamformee
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: MCS 0-9
6 streams: MCS 0-9
7 streams: MCS 0-9
8 streams: MCS 0-9
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: MCS 0-9
6 streams: MCS 0-9
7 streams: MCS 0-9
8 streams: MCS 0-9
VHT TX highest supported: 0 Mbps
VHT extended NSS: supported
HE Iftypes: managed
HE MAC Capabilities (0x000b9a181040):
+HTC HE Supported
TWT Requester
Dynamic BA Fragementation Level: 1
BSR
Broadcast TWT
OM Control
Maximum A-MPDU Length Exponent: 3
RX Control Frame to MultiBSS
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c604c897fdf839c010c00):
HE40/HE80/5GHz
HE160/5GHz
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
STBC Tx <= 80MHz
STBC Rx <= 80MHz
Full Bandwidth UL MU-MIMO
DCM Max Constellation: 1
DCM Max Constellation Rx: 1
SU Beamformer
SU Beamformee
MU Beamformer
Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 3
Sounding Dimensions <= 80Mhz: 7
Sounding Dimensions > 80Mhz: 3
Ng = 16 SU Feedback
Ng = 16 MU Feedback
Codebook Size SU Feedback
Codebook Size MU Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
STBC Rx > 80MHz
HE ER SU PPDU 4x HE-LTF 0.8us GI
TX 1024-QAM
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
PPE Threshold 0x7f 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71
HE Iftypes: AP
HE MAC Capabilities (0x000d9a181040):
+HTC HE Supported
TWT Responder
Dynamic BA Fragementation Level: 1
BSR
Broadcast TWT
OM Control
Maximum A-MPDU Length Exponent: 3
RX Control Frame to MultiBSS
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c604c887fdf839c010c00):
HE40/HE80/5GHz
HE160/5GHz
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
STBC Tx <= 80MHz
STBC Rx <= 80MHz
Full Bandwidth UL MU-MIMO
DCM Max Constellation Rx: 1
SU Beamformer
SU Beamformee
MU Beamformer
Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 3
Sounding Dimensions <= 80Mhz: 7
Sounding Dimensions > 80Mhz: 3
Ng = 16 SU Feedback
Ng = 16 MU Feedback
Codebook Size SU Feedback
Codebook Size MU Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
STBC Rx > 80MHz
HE ER SU PPDU 4x HE-LTF 0.8us GI
TX 1024-QAM
RX 1024-QAM
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
PPE Threshold 0x7f 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71
HE Iftypes: mesh point
HE MAC Capabilities (0x00098a081040):
+HTC HE Supported
Dynamic BA Fragementation Level: 1
BSR
OM Control
Maximum A-MPDU Length Exponent: 1
RX Control Frame to MultiBSS
A-MSDU in A-MPDU
OM Control UL MU Data Disable RX
HE PHY Capabilities: (0x0c600c807d5f811c000000):
HE40/HE80/5GHz
HE160/5GHz
LDPC Coding in Payload
HE SU PPDU with 1x HE-LTF and 0.8us GI
STBC Tx <= 80MHz
STBC Rx <= 80MHz
SU Beamformer
SU Beamformee
Beamformee STS <= 80Mhz: 7
Beamformee STS > 80Mhz: 3
Sounding Dimensions <= 80Mhz: 7
Sounding Dimensions > 80Mhz: 3
Ng = 16 SU Feedback
Codebook Size SU Feedback
PPE Threshold Present
HE SU PPDU & HE PPDU 4x HE-LTF 0.8us GI
Max NC: 3
HE RX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set <= 80 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
PPE Threshold 0x7f 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71 0x1c 0xc7 0x71
Frequencies:
* 5180.0 MHz [36] (23.0 dBm)
* 5200.0 MHz [40] (23.0 dBm)
* 5220.0 MHz [44] (23.0 dBm)
* 5240.0 MHz [48] (23.0 dBm)
* 5260.0 MHz [52] (23.0 dBm) (radar detection)
* 5280.0 MHz [56] (23.0 dBm) (radar detection)
* 5300.0 MHz [60] (23.0 dBm) (radar detection)
* 5320.0 MHz [64] (23.0 dBm) (radar detection)
* 5500.0 MHz [100] (30.0 dBm) (radar detection)
* 5520.0 MHz [104] (30.0 dBm) (radar detection)
* 5540.0 MHz [108] (30.0 dBm) (radar detection)
* 5560.0 MHz [112] (30.0 dBm) (radar detection)
* 5580.0 MHz [116] (30.0 dBm) (radar detection)
* 5600.0 MHz [120] (30.0 dBm) (radar detection)
* 5620.0 MHz [124] (30.0 dBm) (radar detection)
* 5640.0 MHz [128] (30.0 dBm) (radar detection)
* 5660.0 MHz [132] (30.0 dBm) (radar detection)
* 5680.0 MHz [136] (30.0 dBm) (radar detection)
* 5700.0 MHz [140] (30.0 dBm) (radar detection)
* 5720.0 MHz [144] (disabled)
* 5745.0 MHz [149] (disabled)
* 5765.0 MHz [153] (disabled)
* 5785.0 MHz [157] (disabled)
* 5805.0 MHz [161] (disabled)
* 5825.0 MHz [165] (disabled)
* 5845.0 MHz [169] (disabled)
* 5865.0 MHz [173] (disabled)
* 5885.0 MHz [177] (disabled)
valid interface combinations:
* #{ managed } <= 1, #{ AP, mesh point } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Maximum associated stations in AP mode: 128
Supported extended features:
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ ACK_SIGNAL_SUPPORT ]: ack signal level support
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
* [ ENABLE_FTM_RESPONDER ]: enable FTM (Fine Time Measurement) responder
* [ STA_TX_PWR ]: TX power control per station
* [ VLAN_OFFLOAD ]: VLAN offload support
* [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
* [ BSS_COLOR ]: BSS coloring support
* [ POWERED_ADDR_CHANGE ]: can change MAC address while up
root@OpenWrt:~#
Interesting bit from above:
HE RX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
HE TX MCS and NSS set 160 MHz
1 streams: MCS 0-11
2 streams: MCS 0-11
3 streams: MCS 0-11
4 streams: MCS 0-11
5 streams: MCS 0-11
6 streams: MCS 0-11
7 streams: MCS 0-11
8 streams: MCS 0-11
160mhz @ 8x8 - that looks impressive! EDIT: on default bdf it was only 4 streams. and obviously 80mhz only.
But I am just guessing, probably I am wrong.
that doesnt has to be 3 radios. it can be 8x8 + 4x4
1 Like
okay, the original bdwlan.bin from the zyxel firmware says the first phy is 8x8
linux:/xfs/zyxel/_V1.00(ABSK.7)C0.bin.extracted/squashfs-root-0 # hexdump -s 1040 -n 64 -C bdwlan.bin
00000410 55 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |U...............|
00000420 00 00 00 00 ff 00 ff 00 00 00 00 00 00 00 00 00 |................|
00000430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
at 0x424 you see the rx chainmask and on 0x426 the tx chainmask
phy1 is 4x4
linux:/xfs/zyxel/_V1.00(ABSK.7)C0.bin.extracted/squashfs-root-0 # hexdump -s 1208 -n 64 -C bdwlan.bin
000004b8 aa 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004c8 0f 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
format as follows with the offset from the operationflags (vht160 etc)
u32 opflags;
u32 featureenable; (unused)
u32 miscconfiguration; (qca9000 only for 6g)
u32 reserved;
u32 txmask2g;
u32 rxmask2g;
u32 txmask5g;
u32 rxmask5g;
so from all i can see .the zyxel is 8x8 + 4x4 radio and there is no third radio running.
consider that no matter if 2 or 3 radios. this is all controled by a single wifi chip. this chip can be configured in different ways. so 3 radios, 2 radios. whatever. also the antenna assignment is variable
3 Likes
thank you!
I put https://github.com/qosmio/openwrt-ipq/blob/qualcommax-6.x-nss-ath11k-2.12/package/kernel/mac80211/patches/nss/ath11k/999-802-ath11k-fixup-thermal-throttle.patch and 999-818-ath11k-bdf-removeregdomain.patch The route cannot be started. delete 999-818-ath11k-bdf-removeregdomain.patch everything's fine. Did you apply both patches?
Works fine on ipq6000/linksys_mnr7350
[ 20.020491] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 20.020566] ath11k c000000.wifi: fw_version 0x2c058558 fw_build_timestamp 2024-07-11 16:18 fw_build_id WLAN.HK.2.12-01368-QCAHKSWPL_SILICONZ-1
[ 20.051194] ath11k c000000.wifi: remove regdomain0 0x00
[ 20.051262] ath11k c000000.wifi: remove regdomain1 0x02
[ 20.055258] ath11k c000000.wifi: bdf template revision v1.2.3, boardrev 39, patch to v1.4.3
[ 20.074594] ath11k c000000.wifi: remove regdomain0 0x833a
[ 20.074657] ath11k c000000.wifi: remove regdomain1 0x02
[ 20.079024] ath11k c000000.wifi: bdf template revision v1.0.5, boardrev 19, patch to v1.4.3
[ 20.227166] ath11k c000000.wifi: htt event 48 not handled
[ 20.231967] ath11k c000000.wifi: nss init soc nss if_num 203 userpd_id 0
PA country
root@MR7350:~# iw reg get
global
country PA: DFS-FCC
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 36), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 30), (N/A), AUTO-BW
(5470 - 5725 @ 160), (N/A, 30), (N/A)
(5725 - 5850 @ 80), (N/A, 36), (N/A)
(57000 - 64000 @ 2160), (N/A, 43), (N/A)
phy#1 (self-managed)
country PA: DFS-UNSET
(2402 - 2472 @ 40), (6, 36), (N/A)
(5170 - 5250 @ 80), (N/A, 30), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (N/A), AUTO-BW
(5490 - 5730 @ 160), (N/A, 24), (N/A), AUTO-BW
(5735 - 5835 @ 80), (N/A, 30), (N/A), AUTO-BW
phy#0 (self-managed)
country PA: DFS-UNSET
(2402 - 2472 @ 40), (6, 36), (N/A)
(5170 - 5250 @ 80), (N/A, 30), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (N/A), AUTO-BW
(5490 - 5730 @ 160), (N/A, 24), (N/A), AUTO-BW
(5735 - 5835 @ 80), (N/A, 30), (N/A), AUTO-BW
On 5GHz, channel 40, 80MHz I can get maximum 27dbm
On 2.4GHz channel 6, 40Mhz I can get maximum 28dbm
Is it possible to get 30/36dbm on both radios?
the maximum power limit is 31,5 dbm. of course its possible to modify the maximum power limits in the caldata, but this is also risky for the health of your device
2 Likes