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).
Wi-Fi usage
Channels 1 up to 11
Channels 12 and 13
Channel 14
Scan
Active/passive scan is allowed but using GLOBAL/WORLD Tx power
Only passive scan
is allowed
Only passive scan
is allowed
STA
Start in GLOBAL/WORLD to join (association).
Once joined/connected to an AP, rely on 11.d information.
According to 11.d country information:
Switch to FCC, ETSI or JP
Stay in GLOBAL if no country code
If AP detected on the requested
channel, switch to ETSI.
If AP detected on the requested
channel, switch to JP.
soft-AP
Stay in GLOBAL/WORLD mode
Forbidden
Forbidden
TEST-FEATURE mode
Reg_mode or without Reg_mode then uses the Tx power without reduction from OTP table inside the chip.
Reg_mode or without Reg_mode then uses the Tx power without reduction from OTP table inside the chip.
Reg_mode or without Reg_mode then uses the Tx power without reduction from OTP table inside the chip.
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
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:
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.
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.
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.
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.
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 :
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.
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).
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
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).
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
hostapd/wpa_supplicant configuration fields
hostapd_WPA3.conf
wpa_supplicant_WPA3.conf
comments
interface=wlan0
optional in hostapd config. Can be set via command line '-i' field
# The wpa field is a bit field that can be used to enable WPA/WPA2
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
wpa_key_mgmt=SAE
key_mgmt=SAE
SAE = 'Simultaneous Authentication of Equals' for WPA3-Personal
rsn_pairwise=CCMP
pairwise=CCMP
# 2 'pairwise' fields are used for WPA or RSN: wpa_pairwise and rsn_pairwise
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
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:
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:
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.
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
When the host CPU is not sending frame to WF200 then the WUP pin should be low in order the WF200 stops the SPI or SDIO interface power consumption during the associated sleep time period (see AN1219 appendix B).
The SPI or SDIO clock should be stopped when the WUP pin is low.
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
This points to an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
If the QUEUE length is short (below 24x bytes), there is only 1 CRC: the final one. The message is then related to a 'sunxi data error'.
If the QUEUE length is long (more than 24x bytes), there are intermediate CRCs. The message is then related to a 'wfx-sdio read error'
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.
From 61e1e589ce720235ddd0e2d569c5d81fe155ed1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
Date: Wed, 22 Apr 2020 10:10:30 +0200
Subject: [PATCH] bh: try to detect duplicated IRQs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bitThe allwinner architecture seems to have some race conditions while
masking the IRQs. So, in some case the IRQ is reported twice to the
driver, then the control register is read twice and data is read twice.Until now, the duplicated access to the control register always happens
before the access to the data (note that it does not prove it will be
always the case). Thus, it is easy to detect that pattern and drop the
faulty access.Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
bh.c | 5 +++++
hwio.c | 7 +++++++
wfx.h | 2 ++
3 files changed, 14 insertions(+)diff --git a/bh.c b/bh.c
index 55724e4295..dd6b4095d3 100644
--- a/bh.c
+++ b/bh.c
@@ -287,6 +287,10 @@ void wfx_bh_request_rx(struct wfx_dev *wdev)
u32 cur, prev;
control_reg_read(wdev, &cur);
+ if (cur == ~0) {
+ dev_warn(wdev->dev, "drop probably duplicated IRQ\n");
+ return;
+ }
prev = atomic_xchg(&wdev->hif.ctrl_reg, cur);
complete(&wdev->hif.ctrl_ready);
queue_work(system_highpri_wq, &wdev->hif.bh);
@@ -324,6 +328,7 @@ void wfx_bh_poll_irq(struct wfx_dev *wdev)
start = ktime_get();
for (;;) {
control_reg_read(wdev, ®);
+ wdev->last_read_reg_is_ctrl = false;
now = ktime_get();
if (reg & 0xFFF)
break;
diff --git a/hwio.c b/hwio.c
index 777217cdf9..ee2fbc112d 100644
--- a/hwio.c
+++ b/hwio.c
@@ -34,6 +34,11 @@ static int read32(struct wfx_dev *wdev, int reg, u32 *val)
*val = ~0; // Never return undefined value
if (!tmp)
return -ENOMEM;
+ if (reg == WFX_REG_CONTROL && wdev->last_read_reg_is_ctrl) {
+ kfree(tmp);
+ return 0;
+ }
+ wdev->last_read_reg_is_ctrl = !!(reg == WFX_REG_CONTROL);
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, tmp,
sizeof(u32));
if (ret >= 0)
@@ -149,6 +154,7 @@ static int indirect_read(struct wfx_dev *wdev, int reg, u32 addr,
goto err;
}
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv, reg, buf, len);
err:
@@ -235,6 +241,7 @@ int wfx_data_read(struct wfx_dev *wdev, void *buf, size_t len)
WARN((long)buf & 3, "%s: unaligned buffer", __func__);
wdev->hwbus_ops->lock(wdev->hwbus_priv);
+ wdev->last_read_reg_is_ctrl = false;
ret = wdev->hwbus_ops->copy_from_io(wdev->hwbus_priv,
WFX_REG_IN_OUT_QUEUE, buf, len);
_trace_io_read(WFX_REG_IN_OUT_QUEUE, buf, len);
diff --git a/wfx.h b/wfx.h
index 3ea3a41216..dbb4870ecc 100644
--- a/wfx.h
+++ b/wfx.h
@@ -101,6 +101,8 @@ struct wfx_dev {
struct hif_rx_stats rx_stats;
struct mutex rx_stats_lock;
+
+ bool last_read_reg_is_ctrl;
};
struct wfx_vif {
--
2.26.1
Wi-Fi Knowledge Base
WF200, WFM200, WGM160P : Country code and regulatory domain
The Wi-Fi firmware used by WF200 or WFM200 or the WGM160P, uses the following regulatory modes:
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).
Active/passive scan is allowed but using GLOBAL/WORLD Tx power
is allowed
is allowed
Start in GLOBAL/WORLD to join (association).
Once joined/connected to an AP, rely on 11.d information.
According to 11.d country information:
If AP detected on the requested
channel, switch to ETSI.
If AP detected on the requested
channel, switch to JP.
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:
WF(M)200 and WGM160P : regulatory RF Certification test-feature usage
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:
For customer using EFR32 like a host processor for WF(M)200:
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 :
For general explanations and recommendation for regulatory RF certifications, we recommend to read this Application Note:
WGM160P : get started with open software using FullMAC driver
Please find below useful information and links to get started with the WGM160P Wi-Fi module:
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
WF(M)200 : Relative and Absolute CCA Modes for RF certifications
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.
WF(M)200 RF Coexistence and PTA usage with another 2.4GHz device
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 :
A general learning-center Wi-Fi coexistence page:
WF(M)200 : Linux WPA3 configuration
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.
Pre-requisites
WPA3 is working as from
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 wlan0AP: Checking wlan0 IP address
ip addr show wlan0AP: 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.200AP 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 hostapdsudo hostapd -i wlan0 hostapd_WPA3.confAP 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 -vChecking if hostapd is running, and what the interface and configuration file are
ps -few | grep hostapdChecking active lines in hostapd configuration (skipping empty lines and comment lines)
cat hostapd_wpa3.conf | grep -v ^$ | grep -v ^#Checking hostapd status
hostapd_cli statusChecking hostapd configuration
hostapd_cli get_configExternal AP checks (from a Linux Wi-Fi STAtion)
wpa_cli scanwpa_cli scan_resultsAP hostapd messages during STA association
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.confSTA 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 -vChecking if wpa_supplicant is running, and what the interface and configuration file are
ps -few | grep wpa_supplicantChecking active lines in wpa_supplicant configuration (skipping empty lines and comment lines)
cat wpa_supplicant_WPA3.conf | grep -v ^$ | grep -v ^#Checking wpa_supplicant status
wpa_cli statusSTA wpa_supplicant messages upon connection
STA: Checking wlan0 IP address
ip addr show wlan0WPA3 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:
Legend
# bit0 = WPA (IEEE 802.11i/D3.0)
# bit1 = WPA2 (IEEE 802.11i/RSN) (dot11RSNAEnabled)
# We don't use WPA: bit0 = 0
# WPA2 and WPA3 use RSN: bit1 = 1
# this leads to wpa=2 / proto=RSN
# we only use RSN, so only set rsn_pairwise
# the value is a space-separated list of accepted encryption algorithms
# CCMP = AES in Counter mode with CBC-MAC (CCMP-128)
# PMF required: ieee80211w=2
# WPA3-Personal-only mode: ieee80211w=2 / key_mgmt=SAE
# wpa_passphrase is an ASCII passphrase, converted to PSK (Pre-Shared Key)
Double quotes required in wpa_supplicant.conf
WF(M)200 : Linux wpa_supplicant.conf to be associated with a Wi-Fi Access Point in WPA3
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:
WF(M)200 : Explanations how the Wi-Fi power limitation from the Host is applied
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.
WF200, WFM200 current consumption : list of things to take care
Please find below a short list of things to check when targeting low current consumption when the Wi-Fi power save mode is enabled:
1) The LP_CLK (32.768KHz +/-1000ppm) has to be provided (not useful if you don't care about current consumption).
2) The frequency drift of LP_CLK within 1 second should be lower than +/-100ppm.
3) The WUP signal should be connected between the host and the WF(M)200.
4) The WUP and WIRQ management should be carefully done to optimize the current consumption (see the source code of WFX driver examples provided on Github).
5) The SPI or SDIO clock should be the highest (respectively 42MHz and 50MHz) to reduce data and management transfer time between the host and the WF(M)200.
6) The resistor pull-up on SDIO interface could increase the current consumption (should be in the host according to the SDIO standard).
7) The WF(M)200 GPIOs usage like FEM or PTA will add additional current consumption on WF(M)200.
8) All pull-up/pull-down resistors on used WF(M)200 GPIOs could impact greatly the average current consumption.
9) Power limitation in Tx or backoff usage could reduce the current consumption in TX (but this also reduces the coverage).
10) VDD_RF, VDD_D, VDD_IO could use 1.8V to reduce power consumption (or 3.3V) but VDD_PA uses only 3.3V nominal (see WF200 or WFM200 datasheet operating conditions).
VDD_IO could be only set to 1.8V If the SPI or SDIO host interface support 1.8V (check also this for other signals like WUP/WIRQ...).
Off course these previous items are some basics and the customer should take care to the host consumption and data traffic usage.
To reduce power consumption, it is recommended to use short high bit rate time slot for transmission or reception and then to be without data traffic during as long time duration as possible.
The AN1219 provides some additional details about this (see https://www.silabs.com/documents/public/application-notes/an1219-power-consumption-wfm200.pdf).
See also https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/03/05/kba_wfx200_dtim3-tmpo and https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/03/19/kba_how_to_do_curr-U9le
KBA: WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
WF200/WFM200 Linux Driver with AllWinner SoC (SDIO)
The information in this article is specific to using the wfx driver in SDIO with AllWinner SoCs on Linux.
The allwinner architecture seems to have some race conditions while masking the SDIO IRQs.
In some case the IRQ is reported twice to the wfx driver, then the control register is read twice and data is read twice.
This subject is discussed in this Linux Kernel discussion Thread
This points to an existing limitation/issue in the AllWinner SDIO HW/Driver combination related to SDIO IRQ masking.
This leads to 2 consecutive read of CONTROL, followed by 2 consecutive read of QUEUE.
As this (2 consecutive QUEUE read) is not expected by the FW, SDIO data (i.e. CRC) is incorrect, and the communication is stopped.
There are 2 possible error messages, depending on the first CRC location:
At the time of writing, no correction to the AllWinner 'sunxi-mmc' driver has been implemented, so the solution is to detect the double SDIO IRQs with the wfx driver and drop them.
A 'workaround/patch' has been created for this purpose.
Symptoms
The following error messages should make you consider applying the workaround patch if using SDIO with an AllWinner SoC:
sunxi-mmc 1c12000.mmc: data error, sending stop command
wfx-sdio mmc1:0001:1: wfx_data_read: bus communication error: -110
Workaround Patch
This patch suppresses consecutive reads of CONTROL and QUEUE. It can be applied on driver 2.4.