This KBA is in fact a link to an answered question on the WI-Fi forum about this topic:

https://www.silabs.com/community/wireless/wi-fi/forum.topic.html/wf200_wfm200_transferrate-szfp

The WF200, WFM200 and WGM160P could use antenna diversity mechanism which could improve the Tx/Rx level with the associated Access Point.

Please note this feature is only available in Wi-Fi station mode only. So it is not possible in Soft AP mode neither in combo mode with Wi-Fi soft-AP and station mode (see UG404 section 3.8).

For this the RF1 and RF2 should be used with an antenna. Don't forget to remove the eventual 50ohm resistor to ground set on RF2.
Moreover, you should set the PDS file with the following settings:

/********************/
/* RF configuration */
/********************/
RF_ANTENNA_SEL_DIV_CFG: {
//
// Antenna selection: allows to select the RF port used. Can be different for Tx and Rx (FEM case)
// - TX1_RX1: RF_1 used (default)
// - TX2_RX2: RF_2 used
// - TX1_RX2: Tx on RF_1 and Rx on RF_2
// - TX2_RX1: Tx on RF_2 and Rx on RF_1
// - TX12_RX12: antenna diversity case: both Tx and Rx on the same RF port which is automatically selected (requires DIVERSITY to be set)
//
RF_PORTS: TX12_RX12,
//
// Diversity control mode:
// - OFF (default)
// - INTERNAL : requires RF_PORTS to be set to TX12_RX12
//
DIVERSITY: INTERNAL
},

Don't forget to compress this PDS file like described in UG404.

If you have WF200 usage in station mode only then the antenna diversity allow to improve the throughput in the coverage area in selecting the best antenna.
It also allow to improve the global coverage area on some area on the border.
Antenna diversity allows to use the best antenna providing an increased Tx/Rx level at the Wi-Fi station level.
The antenna diversity in station mode benefit is visible when the Rx power level is lower on one RF antenna and higher on the other and globally for low signal level.
In this case the best Rx level is chosen and this allow to maintain a higher throughput or even in some condition the Wi-Fi link.

Note the antenna diversity doesn't allow you to increase the TX power because only one antenna is used after each antenna selection.
In order to increase the Tx power and the coverage in soft AP or station mode, you could use a FEM like described with WF200 in  AN1226.

The Wi-Fi firmware used by WF200 or WFM200 or the WGM160P, uses the following regulatory modes:

• FCC :        Maximum Tx power per channel is extracted from FCC OTP table inside the chip. Channels 12,13,14 are not used.
• CE/ETSI : Maximum Tx power per channel is extracted from ETSI OTP table inside the chip. Channels 14 is not used.
• JP :           Maximum Tx power per channel is extracted from JP OTP table inside the chip. Note that for channels <14 the ETSI values are used.
• GLOBAL/WORLD : The minimum of all maximum Tx power allowed by region in the OTP table inside the chip is used. Depending of the context channels 12,13,14 may not be used.

WF(M)200 can be used either in WLAN mode or in TEST_FEATURE mode through the PDS file (see UG404, mode without MAC and association to a Wi-Fi access point).

The goal is to avoid any regulatory RF infringement in WLAN mode. Note the passive scan provides a result with an increased time duration than the active scan.

At the MAC level on Country code and regulatory domain, this setting below should be done:

• in WLAN mode
  • With a Linux Host using the lower MAC:
    • STA: The country code is retrieved from the AP’s beacon
    • SoftAP: the country code is set in the hostapd configuration file
    • The country code is processed using CRDA (Central Regulatory Domain Agent) to transform a  country code (US/FR/GB/JP/…) into a regulatory domain (DFS-ETSI/FCC/JPN)
  • With a MCU using the full MAC:
    • STA: The country code is retrieved from the AP’s beacon in the Full MAC driver API
    • SoftAP: the country code is set in the Full MAC driver API
• in TEST-FEATURE mode
  • the regulatory domain could be set manually using TEST_FEATURE_CFG:REG_MODE in the PDS file

(Linux) Checking regulatory domain information

iw reg get

result:

global
country US: DFS-FCC
        (2402 - 2472 @ 40), (N/A, 30), (N/A)
        (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
        (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
        (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
        (5735 - 5835 @ 80), (N/A, 30), (N/A)
        (57240 - 63720 @ 2160), (N/A, 40), (N/A)

(Linux) Checking channel settings

 iw phy | grep MHz

result:

                        * 2412 MHz [1] (30.0 dBm)
                        * 2417 MHz [2] (30.0 dBm)
                        * 2422 MHz [3] (30.0 dBm)
                        * 2427 MHz [4] (30.0 dBm)
                        * 2432 MHz [5] (30.0 dBm)
                        * 2437 MHz [6] (30.0 dBm)
                        * 2442 MHz [7] (30.0 dBm)
                        * 2447 MHz [8] (30.0 dBm)
                        * 2452 MHz [9] (30.0 dBm)
                        * 2457 MHz [10] (30.0 dBm)
                        * 2462 MHz [11] (30.0 dBm)
                        * 2467 MHz [12] (disabled)
                        * 2472 MHz [13] (disabled)
                        * 2484 MHz [14] (disabled)
                 * short GI for 40 MHz

• '(disabled)' means the channel can't be used
• '(no IR)' means no active scan is allowed

For RF tests in laboratory or for regulatory RF certification tests, the WF200, WFM200 or WGM160P could be started in RF test-feature using the PDS file in adding the section TEST_FEATURE_CFG with the selected parameter for Tx or Rx like described in UG404 section 4.
This test-feature doesn't need a Wifi Acces Point to transmit or receive frames. There is no 802.11 MAC protocol used in this mode. It is only to be used to test the RF behavior in Tx or in Rx.

The customer could use the PDS file to do RF tests but with a host implementing Python, it could be more easy to use the Python script to configure and control the RF tests:

• The documentation to use the Python script is github.com/SiliconLabs/wfx-common-tools/test-feature/README.md 
• The Python functions configure the RF test mode using PDS file using the following PDS data structure :  https://github.com/SiliconLabs/wfx-common-tools/test-feature/README.md#test-data-structure 
• The Python test-feature API is provided  with : wfxtestdut-api-functions

Note the WLAN mode needs to be stopped before starting RF test-feature.

For customer using EFR32 like a host processor for WF(M)200:

• Send precompiled PDS test-feature field from your application (Simpler and fine for limited testings)
• Port the RF test agent available on GitHub in your MCU: 
  • https://github.com/SiliconLabs/wfx-fullMAC-tools/tree/master/Tools/sl_wfx_common_cli/sl_wfx_rf_test_agent
  • Implementation examples are available in the uart_cli application : https://github.com/SiliconLabs/wfx-fullMAC-tools/tree/master/Examples/SiliconLabs/uart_cli
  • With this software on your device, you can use the Python tool to send RF test mode commands to the WF(M)200. It is more suitable for extended testing.

Note the RF test done with WGM160P using Gecko OS is already described in this KBA: 
https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/10/15/wgm160p_certificationtestingusinganexampleap-lwPV

So through the PDS file test-feature, you have a way to do RF tests but in order to pass RF certification, it is usual to adjust the Tx power in order to get the RF requirement depending of the regulatory certification targeted.

Indeed depending of the antenna or the RF layout or the design of the customer product, it is possible the TX power shall be reduced in order to pass the regulatory RF certification (FCC, CE, Japan, ...).

Please on RF and certification aspect, follow carefully the requirements and recommendations provided in the WF200, WFM200 or WGM160P datasheets and the Hardware Design User's Guide (see UG382, UG395 or UG384).

The Tx power level reduction is done using BACKOFF_QDB in the RF_POWER_CFG Section in the PDS file (see section 3.7 of UG404).
With the Python test-feature script, the customer could use the function tx_backoff(mod, backoff_level) in order to reduce the Tx power.
The Tx power level optimization using the backoff could be done versus PHY rate group and the Wi-FI channels.
It is not recommended to use the function tx_power(dBm) to reduce the Tx power because it set only a Tx power limitation for all cases (all PHY rate and all channels).
The function tx_power(dBm) is related to MAX_OUTPUT_POWER_QDBM in the PDS file in quarter of dBm. It is only a Tx power level limitation. It can’t be used to increase the Tx power above the calibrated levels done with default backoffs stored during production (for example higher than expected for the RF certification or provided in the datasheet).

Please note for WFM200 and WGM160P which has been pre-certified for some regulatory regions (see the related datasheet), the customer should use the function regulatory_mode(reg_mode) to set the targeted region in order to use the internally stored Tx power backoff for this pre-certified module before to do measurement using the test-feature with the final product. In this case, the function tx_backoff adds only an additional Tx power reduction needed to meet the RF requirement with the customer product.
The function regulatory_mode is related to REG_MODE in the PDS file. The REG_MODE is only used in test-feature mode (not in wlan mode).

After the customer has passed the regulatory RF certification with this product using the test-feature in adding eventually some TX power reduction using backoff and eventually the  regulatory_mode then it remains to use the table of backoff  in the PDS used in production in WLAN mode.

A very interesting example is provided in https://github.com/SiliconLabs/wfx-common-tools/blob/master/test-feature/certification.md

This allows in wlan mode (STA or soft AP) to follow the Tx power level required by the regulatory RF certification.
Please note the customer could store several PDS files for different regulatory region (with different backoff). The selected PDS is used in the product when the regulatory region is known.
Another way using only one PDS file is to use only one PDS with the higher backoff of the different targeted regulatory region.

Read also this KBA : 

• KBA Explanations how the Wi-Fi power limitation from the Host is applied 
• KBA CCA modes for certification
• KBA explanations about country code usage

For general explanations and recommendation for regulatory RF certifications, we recommend to read this Application Note:

• https://www.silabs.com/documents/public/application-notes/an1048-regulatory-certifications.pdf

Please find below useful information and links to get started with the WGM160P Wi-Fi module:

• Examples running on the WGM160P are provided on GitHub: https://github.com/SiliconLabs/wfx-fullMAC-tools
• They use the FMAC driver also available on GitHub: wfx-fullMAC-driver
• The driver documentation is available on docs.silabs.com/wifi/
• In addition, you can find the WGM160P Wi-Fi commissioning example getting started: wgm160/getting-started
• Make sure the WGM160P you have has the correct bootloader: wgm160p/bootloader/README.md

Another useful WGM160P getting started using Micrium OS could be found here:

https://www.silabs.com/community/wireless/wi-fi/forum.topic.html/wgm160p_getting_startedwithmicriumosandfullma-vRQD 

For WF200, WFM200 or WGM160P, the firmware uses by default the Relative CCA mode which automatically set the CCA level.

This default mode is not recommended to pass the CE RF certification for the adaptivity test. Indeed for this certification the Absolute CCA mode shall be selected.

If you are using the Full-MAC API this could be set with SL_WFX_CCA_THR_MODE_ABSOLUTE using this https://docs.silabs.com/wifi/wf200/rtos/latest/group-g-e-n-e-r-a-l-d-r-i-v-e-r-a-p-i#ga033dca6edbef96e4042d500a10dff9d8

if you are using Lower MAC and Linux driver wfx then you could modify the CCA mode sending a specific frame after the firmware download like this (within a root session only):
# Absolute CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x01\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg

In order to revert CCA mode in default mode Relative, you could do this below or to reload the firmware:
# Relative CCA mode :
echo -en "\x0c\x00\x06\x04\x03\x20\x04\x00\x00\x00\x00\x00" > /sys/kernel/debug/ieee80211/phy*/wfx/send_hif_msg

Note in the above path, the * in "phy*" could be replaced by an index depending of your target.

This is also indicated in the UG395 in section 8.3 but it could be useful for WF200 or WGM160P.

This short KBA provides some key links related to RF coexistence recommendations with WF200, WFM200 and WGM160P.

WF(M)200 implements a PTA arbiter which allows to improve the RF coexistence with another 2.4GHz device. This is very useful when the product is small with co-located antenna. The following link provides an application note on this topic: https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence

Even when implementing managed coexistence with PTA mechanism, you should take care to unmanaged coexistence principles : https://docs.silabs.com/wifi/wf200/content-source/application-note/wifi-coexistence#unmanaged-coexistence

Off course, the 2.4GHz coexistence is a sharing and so the throughput and/or packet delay could be impacted for both or for one device. It will be difficult to target high throughput and short delay with two or more devices sharing the 2.4 GHz. If you target moderate Wi-Fi throughput like 10 or 15 Mbps then the sharing should be easy. If you target low Wi-Fi throughput then may be the PTA is not always useful but the interface could be connected for future usage in case of need.

We recommend to add Test Points on used PTA signals to debug and check the configuration on both devices is Ok. 

Note with EFR32 using BLE or Zigbee, only the 3 wires PTA interface is currently available but the 4 wires could be connected for future usage. You could refer to these Application Notes below :

• Zigbee and Thread : https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
• Bluetooth : https://www.silabs.com/documents/public/application-notes/an1128-bluetooth-coexistence-with-wifi.pdf

A general learning-center Wi-Fi coexistence page:

• https://www.silabs.com/products/wireless/learning-center/wi-fi-coexistence

Linux: Configuring WF(M)200 for WPA3

WF(200) can be used with Linux in WPA3 in both AP (Access Point) and STA (STAtion) modes using Linux standard commands.

This article provides generic (i.e. not specific to WF(M)200) information on the Linux configuration of a WPA3 AP as well as a WPA3 STA. You can set up 2 boards and connect them together over WPA3 Wi-Fi.

In most cases, WF(M)200 will act either as AP or STA, not with both roles simultaneously. For commissioning purposes, it is possible to enable simultaneous AP+STA. Details on this feature are not provided in this article.

Pre-requisites

WPA3 is working as from

• wfx-linux-driver version 2.5.2-public
• wfx-firmware version 3.8.0
• wpa_supplicant release v2.8-devel.

Please update to the above minimal versions before using WPA3 with WF(M)200.

AP (Access Point)

The AP uses hostapd, configured via the hostapd_WPA3_wlan0.conf file.

AP: Allocating an IP address to wlan0

sudo dhcpcd --release wlan0
sudo ip addr flush dev wlan0
sudo ip addr add 192.168.45.1/24 dev wlan0

AP: Checking wlan0 IP address

ip addr show wlan0

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:0d:6f:73:91:57 brd ff:ff:ff:ff:ff:ff
    inet 192.168.45.1/24 scope global wlan0
       valid_lft forever preferred_lft forever

AP: DHCP/DNS setup using dnsmasq: allocating an IP address range to wlan0 clients

sudo killall dnsmasq
sudo dnsmasq --conf-file=/dev/null --interface=wlan0 --bind-interfaces --except-interface=lo --dhcp-range=192.168.45.100,192.168.45.200

AP interface selection

The AP wlan interface is selectable in the hostapd command line, as the '-i' (list of interface names to use) field. It can also be hard-coded in the hostapd_WPA3.conf file.

Typical hostapd command line (in the context of our Raspberry Pi demo, user 'pi' (requiring 'sudo'))

sudo killall hostapd

sudo hostapd -i wlan0 hostapd_WPA3.conf

Configuration file: hostapd_WPA3.conf
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan0 with hwaddr 00:0d:6f:73:91:57 and ssid "WPA3_AP"
wlan0: interface state COUNTRY_UPDATE->ENABLED
wlan0: AP-ENABLED

We recommend not running hostapd in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).

AP configuration

Refer to the attached hostapd_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf for details of hostapd configuration.

AP Checks (on the AP)

Checking hostapd version (tested with v2.8-devel)

hostapd -v

hostapd v2.8-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2019, Jouni Malinen <j@w1.fi> and contributors

Checking if hostapd is running, and what the interface and configuration file are

ps -few | grep hostapd

root       986   807  0 09:47 pts/1    00:00:00 sudo hostapd -i wlan0 hostapd_WPA3.conf
root       991   986  0 09:47 pts/1    00:00:00 hostapd -i wlan0 hostapd_WPA3.conf

Checking active lines in hostapd configuration (skipping empty lines and comment lines)

cat hostapd_wpa3.conf | grep -v ^$ | grep -v ^#

driver=nl80211
ctrl_interface=/var/run/hostapd
ctrl_interface_group=netdev
ssid=WPA3_AP
country_code=US
channel=6
auth_algs=1
hw_mode=g
ieee80211n=1
dtim_period=1
max_num_sta=8
wpa=2
wpa_key_mgmt=SAE
rsn_pairwise=CCMP
ieee80211w=2
wpa_passphrase=passphrase

WPA3: Make sure 'SAE' is used for wpa_key_mgmt

Checking hostapd status

hostapd_cli status

Selected interface 'wlan0'
state=ENABLED
phy=phy0
freq=2437
num_sta_non_erp=0
num_sta_no_short_slot_time=0
num_sta_no_short_preamble=0
olbc=0
num_sta_ht_no_gf=0
num_sta_no_ht=0
num_sta_ht_20_mhz=0
num_sta_ht40_intolerant=0
olbc_ht=0
ht_op_mode=0x0
cac_time_seconds=0
cac_time_left_seconds=N/A
channel=6
secondary_channel=0
ieee80211n=1
ieee80211ac=0
beacon_int=100
dtim_period=1
ht_caps_info=000c
ht_mcs_bitmask=ff000000000000000000
supported_rates=02 04 0b 16 0c 12 18 24 30 48 60 6c
max_txpower=30
bss[0]=wlan0
bssid[0]=00:0d:6f:73:91:57
ssid[0]=WPA3_AP
num_sta[0]=1

Checking hostapd configuration

hostapd_cli get_config

Selected interface 'wlan0'
bssid=00:0d:6f:73:91:57
ssid=WPA3_AP
wps_state=disabled
wpa=2
key_mgmt=SAE
group_cipher=CCMP
rsn_pairwise_cipher=CCMP

WPA3: Make sure key_mgmt is 'SAE'

External AP checks (from a Linux Wi-Fi STAtion)

wpa_cli scan

Selected interface 'wlan0'
OK

wpa_cli scan_results

Selected interface 'wlan0'
bssid / frequency / signal level / flags / ssid
00:0d:6f:73:91:57       2437    -47     [WPA2-SAE-CCMP][ESS]    WPA3_AP

WPA3: Make sure 'SAE' is present in the flags

AP hostapd messages during STA association

wlan0: STA 00:0d:6f:73:8a:15 IEEE 802.11: associated (aid 1)
wlan0: AP-STA-CONNECTED 00:0d:6f:73:8a:15
wlan0: STA 00:0d:6f:73:8a:15 RADIUS: starting accounting session DE8CB6C3CD1D354B
wlan0: STA 00:0d:6f:73:8a:15 WPA: pairwise key handshake completed (RSN)

STA (STAtion)

The STA uses wpa_supplicant, configured via the wpa_supplicant_WPA3.conf file.

STA interface selection

The STA wlan interface is selected in the wpa_supplicant command line, as the '-i' (= interface name) field

Typical wpa_supplicant command line (in the context of our Raspberry Pi demo, user 'pi')

sudo killall wpa_supplicant
sudo wpa_supplicant -i wlan0 -c wpa_supplicant_WPA3.conf

We recommend not running wpa_supplicant in the background when experimenting, to get an immediate display of any message from the application. Run in the background once you have validated your setup (use '-B' for running in background).

STA configuration

Refer to the attached wpa_supplicant_WPA3.conf file. Refer to https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf for details of wpa_supplicant configuration.

STA Checks (on the STA)

Checking wpa_supplicant version (tested with 2.8-devel)

wpa_supplicant -v

wpa_supplicant v2.8-devel
Copyright (c) 2003-2019, Jouni Malinen <j@w1.fi> and contributors

Checking if wpa_supplicant is running, and what the interface and configuration file are

ps -few | grep wpa_supplicant

root      5091   846  0 10:10 pts/3    00:00:00 sudo wpa_supplicant -i wlan0 -c wpa_supplicant_WPA3.conf
root      5096  5091  1 10:10 pts/3    00:00:00 wpa_supplicant -i wlan0 -c wpa_supplicant_WPA3.conf

Checking active lines in wpa_supplicant configuration (skipping empty lines and comment lines)

cat wpa_supplicant_WPA3.conf | grep -v ^$ | grep -v ^#

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=0
country=US
network={
    ssid="WPA3_AP"
    proto=RSN
    key_mgmt=SAE
    pairwise=CCMP
    group=CCMP
    ieee80211w=2
    psk="passphrase"
}

WPA3: Make sure that 'SAE' is used for key_mgmt

Checking wpa_supplicant status

wpa_cli status

Selected interface 'wlan0'
bssid=00:0d:6f:73:91:57
freq=2437
ssid=WPA3_AP
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=2
mgmt_group_cipher=BIP
sae_group=19
wpa_state=COMPLETED
ip_address=169.254.95.237
address=00:0d:6f:73:8a:15
uuid=ddc6a32a-0205-5c93-912f-e04979164e16

WPA3: Make sure key_mgmt is 'SAE'

STA wpa_supplicant messages upon connection

wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: SME: Trying to authenticate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: PMKSA-CACHE-ADDED 00:0d:6f:73:91:57 0
wlan0: Trying to associate with 00:0d:6f:73:91:57 (SSID='WPA3_AP' freq=2437 MHz)
wlan0: Associated with 00:0d:6f:73:91:57
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: WPA: Key negotiation completed with 00:0d:6f:73:91:57 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:0d:6f:73:91:57 completed [id=0 id_str=]

STA: Checking wlan0 IP address

ip addr show wlan0

4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:6f:73:8a:15 brd ff:ff:ff:ff:ff:ff
    inet 192.168.45.109/24 brd 192.168.45.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::108f:61b8:531f:3a20/64 scope link
       valid_lft forever preferred_lft forever

Check that the IP address is within the range allocated via dnsmasq on the AP

WPA3 configuration fields table

The table below lists side-by-side parameters present in hostapd.conf and wpa_supplicant for a setup where a Linux platform is configured as AP while another Linux platform is configured as a STA associated with the AP.

These parameters correspond to the attached configuration files:

• hostapd_WPA3_wlan0.conf
• wpa_supplicant_WPA3.conf

Legend

• User-modifiable fields
• WPA3-forced fields

In order to use the WPA3 with the WF(M)200 through Linux, you could use the following wpa_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="WPA3_000"
psk="xxxxxxxxxxxxx"
key_mgmt= SAE
proto=RSN
pairwise=CCMP
group=CCMP
ieee80211w=2
}

Note ieee80211w could be set to 1 or 2. See the definition of the parameters in the https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

With a CISCO AP AIR-AP1852E-E-K9, firmware 8.10.105.0 configured with WPA3 security and a Raspberry Pi with the SD-card 3.2 with BRD8022/23A with FW3.8.0 and the Driver WFX 2.5.2, you could get this with WPA3 security enabled:

First with a Wi-Fi scan, you should get SAE on the security used by the AP with WPA3:

pi@rpi-123:~ $ wfx_sta --scan
Starting  wpa_supplicant
Scanning access points...
bssid / frequency / signal level / flags / ssid
x:x:x:x:x:x       2462    -43     [WPA2-PSK+SAE-CCMP][ESS]        WPA3_000
...

Then using the wpa_supplicant_WPA3.conf above, we could get the association like below:

pi@rpi-123:~ $ wfx_sta --conf wpa_supplicant_WPA3.conf
Asking dhcpcd to control wlan0
Starting  wpa_supplicant
Setting up connection
Waiting for connection
Associated
Waiting for DHCP
DHCP lease obtained
Success: wlan0 connected to WPA3_000 with IP X.X.X.X

Then we could get the following status with wpa_cli:

pi@rpi-123:~ $ wpa_cli status
Selected interface 'wlan0'
bssid=xx:xx:xx:xx:xx:xx
freq=2462
ssid=WPA3_000 
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=SAE
pmf=1
mgmt_group_cipher=BIP
sae_group=19
wpa_state=COMPLETED
ip_address=X.X.X.X

We could check the status indicating key_mgmt=SAE and pmf=1 in bold above because it is associated with an AP using the WPA3 security.

Remarks:

• WPA3 security is now mandatory for all Wi-Fi Alliance certified products but it is relatively new and not supported by all Access Point or station already installed or sold in 2020.
• Please note WPA3 could be not supported with old wpa_supplicant release. We have tested successfully this with a Linux kernel 4.19.57-v7l+ and the wpa_supplicant release v2.8-devel.

When the host asks the WF200 or WFM200 to limit the Tx power, WF(M)200 adds FRONT_END_LOSS_TX_QDB from the requested value (see UG404 on the PDS file).

Hence:

• if FRONT_END_LOSS_TX_QDB is 0, the host controls the power limitation at the output of the RF1 and RF2 pin of WF(M)200

• if FRONT_END_LOSS_TX_QDB is set to antenna gain (negative value) and loss on the board or from a FEM (positive value), the host controls the limitation in EIRP

Note that the Linux hosts work with EIRP values. So, if WF(M)200 aims to work with a Linux host, FRONT_END_LOSS_TX_QDB should be set with the antenna gain.

Note also this is only a Tx output limitation and this limitation could be higher than the WF(M)200 Power Amplifier is allowed or able to transmit depending on RF certification constraint and backoff set in the PDS file according to the channel or the PHY rate.