Wi-Fi Coexistence with Other 2.4 GHz Radio Protocols

This document describes the impact of 2.4 GHz radio protocols on Wi-Fi and methods to improve Coexistence with these protocols. These techniques are applicable to the WF(M)200 Wi-Fi transceiver and the WGM160P Wi-Fi module. First, design considerations to improve Coexistence without direct interaction between 2.4 GHz radios and Silicon Labs Wi-Fi solutions are described. Next, Silicon Labs Packet Traffic Arbitration (PTA) support to coordinate 2.4 GHz RF traffic for co-located 2.4 GHz radios and Silicon Labs Wi-Fi solutions is described.

This document applies for both WF200 and WFM200S. For simplicity, both devices are referred to as WF(M)200. WGM160P embeds the WF200 Wi-Fi solution and is by extension affected by the document.

Introduction

The 2.4 GHz ISM (Industrial Scientific and Medical) band supports Wi-Fi (IEEE 802.11b/g/n), Zigbee/Silicon Labs Thread (IEEE 802.15.4), Bluetooth®, and Bluetooth low energy. The simultaneous and co-located operation of these different 2.4 GHz radio standards can degrade performance of one or more of the radio protocols. To improve interference robustness, each of the 2.4 GHz ISM radio standards support some level of collision avoidance and/or message retry capability.

This document covers the impact of 2.4 GHz radio protocols on a Wi-Fi solution and methods to improve coexistence with those protocols on the following Silicon Labs solutions:

The document describes the initial 2.4 GHz Coexistence problematic and solutions to work around challenges brought up by more and more complex designs.

Radio Protocols Impact on Wi-Fi

World-wide, Wi-Fi (IEEE 802.11b/g/n) supports up to 14 overlapping 20/22MHz bandwidth channels across the 2.4 GHz ISM band with transmit power levels up to +30dBm. Bluetooth supports 40 non-overlapping channels at 2 MHz spacing with transmit power levels up to +20dBm (Bluetooth Core Specification v5.0). 2.4 GHz Zigbee and Thread (based on IEEE 802.15.4) support 16 non-overlapping 2MHz bandwidth channels at 5MHz spacing with transmit powers up to +20dBm. These Wi-Fi, Bluetooth, and Zigbee/Thread channel map-pings are shown in the following Figure.

2.4 GHz Channel Map

Actual channels available vary by country. For example, in Japan, Wi-Fi channels 1 through 14 are available when in Europe only Wi-Fi channels 1 through 13 are allowed. Finally, in the USA, the Wi-Fi channels are restricted between 1 and 11.

Unmanaged Coexistence

The unmanaged coexistence recommendations that follow provide guidance on how to maximize the WF(M)200 message success with nearby 2.4 GHz radio protocols.

Implement Frequency Separation

If possible, maximize the frequency separation between channels used by the WF(M)200 and the CoEx device. If the Wi-Fi and 2.4 GHz radios are implemented with a common host (MCU controlling both radios), the host should attempt to maximize the frequency separation. Acting as a station, the WF(M)200 must comply with the channel used by the access point it is connected to. Acting as an AP (Access Point), the WF(M)200 host selects the channel.

Similarly, most of the 2.4 GHz protocols can be restricted on the channels used. BLE uses a frequency channel hopping algorithm. When the device is master, it can specify a channel map to avoid the channels used by the WF(M)200 Wi-Fi interface.

Use Retry Mechanisms

If the radio protocol allows it, maximize the retry attempts to improve the individual message’s success rate. However, under high-interference conditions, message latency increases and in a mesh network scenario, there is a risk of flooding the network with identical messages.

Hardware Design Considerations

Minimizing the interfering energy seen by the Wi-Fi RF input port improves the Wi-Fi receive range. This can be achieved by:

Managed Coexistence

The market trends of higher Wi-Fi transmit power, higher Wi-Fi throughput, and integration of Wi-Fi and other 2.4 GHz radio protocols into the same device has the following impacts.

Advantages:

Disadvantages:

Managed Coexistence takes advantage of communication between the co-located Wi-Fi and CoEx radios to coordinate each radio’s access to the 2.4 GHz ISM band for transmit and receive.

Warning: The current PTA support for the WF(M)200 is limited to specific use cases. It is recommended to enable the PTA only in station mode. In Wi-Fi access point or simultaneous mode (acting as station and AP), enabling/using the PTA is not recommended.

PTA Modes

Several options offer various benefits and trade-offs between ease-of-use and performances. There are 5 PTA hardware modes which are defined by the number of wires used between the RF devices:

Each mode and the GPIOs usage is explained in detail below.

1-Wire Coex master PTA

In 1-Wire CoEx master PTA, the CoEx device asserts a REQUEST signal when the CoEx radio wants to transmit or receive. When REQUEST is asserted, the Wi-Fi radio can transmit or receive. This mode does not allow the PTA block to grant the 2.4 GHz ISM to the CoEx and is not recommended.

1-Wire WLAN master PTA

In 1-Wire WLAN master PTA, the Wi-Fi/PTA device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the CoEx radio can transmit or receive. This mode does not allow the CoEx radio to request the 2.4 GHz ISM and is not recommended.

2-Wire PTA

In 2-Wire PTA, the REQUEST signal is added, allowing the CoEx radio to request the 2.4 GHz ISM band. The Wi-Fi/PTA device internally controls the prioritization between CoEx and Wi-Fi interfaces. On a conflict, the PTA can choose to either GRANT the CoEx or Wi-Fi.

3-Wire PTA

In 3-Wire PTA, the PRIORITY signal is added, allowing the CoEx radio to signify a high- or low-priority message is either being received or transmitted. The Wi-Fi/PTA device compares this external priority request against the internal Wi-Fi priority, which may be high/low and can choose to either GRANT the CoEx or Wi-Fi.

4-Wire PTA

In 4-Wire PTA, the FREQ signal is added, allowing the CoEx radio to signify an “in-band” or “out-of-band” message is either being received or transmitted. The channel used by the WLAN interface needs to be shared with the CoEx device to allow it to assert or not FREQ. It allows the two RF devices to receive simultaneously but never to send at the same time. Thus the 4-Wire only makes sense when the “combined” / “simultaneous RX access” mode is enabled.

3/4-Wire PTA Combined

The “combined” / “simultaneous RX access” mode allows the PTA to grant simultaneously the RX requests of the CoEx device and the Wi-Fi. It can be applied to the 3-Wire and is mandatory in the 4-Wire PTA modes. When enabled, the PTA samples over the request duration the PRIORITY signal to update the directionality information. If both the CoEx and Wi-Fi requests are RX and the combined mode is enabled, the PTA grants both requests.

PTA Support Options

This section describes the APIs available to configure and use the PTA feature. In addition, it goes over how to configure the PTA using the FMAC driver on microcontroller hosts and the LMAC driver on Linux hosts.

PTA GPIOs Configuration through the PDS

The PDS (Platform Data Set) configures the WF(M)200 hardware. This configuration is sent during the WF(M)200 initialization phase. To learn more about the PDS overall process, refer to the UG404: WF(M)200 Configuration Guide with PDS.

In the PTA context, the WF(M)200 PTA GPIOs need to be configured. It is done using the PDS as described in this section. Depending on the PTA mode used, the required GPIOs to enable differ. The GPIOs associated to the PTA modes are indicated in their respective sections.

This configuration step is mandatory at each WF(M)200 power on reset. The PDS configuration is not maintained through the shutdown/reset state. Without this step, the PTA GPIOs are not functional and none of the signals are going in or out of the WF(M)200.

GRANT Signal GPIO

For PTA modes using the GRANT signal (1-Wire WLAN, 2/3/4-Wire), edit/add the GPIO_PTA_STATUS section in the PROG_PINS_CFG section of the PDS.

GPIO_PTA_TX_CONF: {
    SLEW_RATE: 4,
    PULL_UP_DOWN: none,
    SLEEP_CFG: down,    // “down” or “up”, matching “Grant Signal Active Level” setting
    PIN_MODE: func,     // “func” to enable the PTA GPIO
    GPIO_ID: H
},

“SLEEP_CFG” is configured to match the “Grant Signal Active Level” setting (cf. PTA Settings Request, 0<->“down”, 1<->”up”). Thus, when the WF(M)200 is sleeping, the GPIO_PTA_TX_CONF GPIO maintains the level to grant the CoEx requests.

REQUEST Signal GPIO

For PTA modes using the REQUEST signal (1-Wire CoEx, 2/3/4-Wire), edit/add the GPIO_PTA_RF_ACT section in the PROG_PINS_CFG section of the PDS.

GPIO_PTA_RF_ACT: {
    SLEW_RATE: 4,
    PULL_UP_DOWN: down, // “down” or “up”, matching “Request Signal Active Level” setting
    SLEEP_CFG: none,    
    PIN_MODE: func,     // “func” to enable the PTA GPIO
    GPIO_ID: I
},

“PULL_UP_DOWN” is configured to match the opposite of the “Request Signal Active Level” setting (cf. PTA Settings Request, 1<->“down”, 0<->”up”). Thus, when the CoEx is sleeping, the GPIO_PTA_RF_ACT GPIO maintains a level where the REQUEST signal is not asserted.

PRIORITY Signal GPIO

For PTA modes using the PRIORITY signal (3/4-Wire), edit/add the GPIO_PTA_TX_CONF section in the PROG_PINS_CFG section of the PDS.

GPIO_PTA_STATUS: {
    SLEW_RATE: 4,
    PULL_UP_DOWN: none,
    SLEEP_CFG: none,
    PIN_MODE: func,     // “func” to enable the PTA GPIO
    GPIO_ID: J
},

FREQ Signal GPIO

For PTA modes using the FREQ signal (4-Wire), edit/add the GPIO_PTA_FREQ section in the PROG_PINS_CFG section of the PDS.

GPIO_PTA_FREQ: {
    SLEW_RATE: 4,
    PULL_UP_DOWN: none,
    SLEEP_CFG: none,
    PIN_MODE: func,     // “func” to enable the PTA GPIO
    GPIO_ID: K
},

Finally, the pull-up/-down resistor and the sleep configuration of each GPIOs can be configured to optimize the application power consumption. Once edited, the PDS file can be compressed using pds_compress.py and used by the application host (cf. UG404: WF(M)200 Configuration Guide with PDS).

PTA Firmware Requests

The WF(M)200 PTA module relies on three different requests:

PTA Priority Request

The PTA priority request defines the balance used to arbitrate the Wi-Fi and 2.4 GHz radio interfaces. To ease the use of this command, an enumeration is provided (cf. Table below).

PTA priority enumerationBehavior
PTA_PRIORITY_COEX_MAXIMIZEDMaximizes priority to CoEx, WLAN connection is not ensured
PTA_PRIORITY_COEX_HIGHHigh priority to CoEx, targets low latency to CoEx
PTA_PRIORITY_BALANCEDBalanced PTA arbitration, WLAN acknowledge receptions are protected
PTA_PRIORITY_WLAN_HIGHHigh priority to WLAN, protects WLAN transmissions
PTA_PRIORITY_WLAN_MAXIMIZEDMaximizes priority to WLAN

Those enumerations should cover most of the common use cases. The PTA priority level applies differently depending on the PTA mode used. The PTA priority request can only be sent when the PTA mechanism is turned off (cf. PTA state request). If the PTA is on, the host must call the PTA state request to turn the PTA off first. It calls the PTA priority request with the update configuration. Finally, the PTA can be turned back on.

After the WF(M)200 initialization, the PTA is by default configured with the PTA_PRIORITY_BALANCED priority. If the PTA priority request is not issued, it keeps this configuration.

PTA Settings Request

The PTA settings request allows the host to configure the PTA mode, the combined mode, the active levels on the PTA signals, define the different timings and quotas. To understand the effect of each settings, refer to Table 5, Figure 7. PTA Signal Chronogram using PTA 3-Wire, and Figure 8. PTA Signal Chronogram using PTA 4-Wire. The PTA settings request must be called prior to calling PTA state request.

The PTA settings request can only be sent when the PTA mechanism is turned off (cf. PTA state request). If the PTA is on, the host must call the PTA state request to turn the PTA off first. It calls the PTA settings request with the updated configuration. Finally, the PTA can be turn back on.

PTA settingsCommentsSize (bits)1-Wire CoEx1-Wire WLAN2-Wire3-Wire4-Wire
PTA ModeThe PTA mode:
- 1 wire WLAN master
- 1 wire CoEx master
- 2 wires
- 3 wires
- 4 wires		8xxxxx
Request Signal Active LevelActive level on REQUEST signal (PTA_RF_ACT pin), provided by CoEx to request the RF.8xxxx
Priority Signal Active LevelActive level on PRIORITY signal (PTA_STATUS pin), provided by CoEx to set the priority of the request8xx
Frequency Signal Active LevelActive level on FREQ signal (PTA_FREQ pin), provided by CoEx when CoEx and WLAN share the same band8x
Grant Signal Active LevelActive level on GRANT signal (PTA_TX_CONF pin), generated by PTA to grant the RF access to CoEx8xxxx
CoEx TypeThe CoEx type: · Generic · BLE8
Default Grant StateThe state of the GRANT signal before arbitration at ‘Grant Valid Time’8xxxx
Simultaneous RX AccessBoolean to allow both CoEx and WLAN to receive concurrently, also named Combined mode8xx mandatory
Priority Sampling TimeThe time (in µs) from the CoEx request to the sampling of the priority on PRIORITY signal (1 to 31 µs)8xx
TX RX Sampling TimeThe time (in µs) from the CoEx request to the sampling of the directionality on PRIORITY signal (Priority Sampling Time to 63 µs)8(x)x
Frequency Sampling TimeThe time (in µs) from the CoEx request to the sampling of freq-match information on FREQ signal (1 to 127 µs)8x
Grant Valid TimeThe time (in µs) from CoEx request to the GRANT signal assertion (MAX(Directionality Sampling Time, Frequency Sampling Time) to 255 µs)8xx
FEM Control TimeThe time (in µs) from CoEx request to the control of FEM (Grant Valid Time to 255 µs)8xx
First Slot TimeThe time (in µs) from the CoEx request to the beginning of reception or transmission (Grant Valid Time to 255 µs)8(x)x
Periodic TX RX Sampling TimeThe period (in µs) between each directionality samplings on PRIORITY signal (1 to 1023 µs). Starts from First Slot Time.8(x)x
CoEx QuotaThe duration (in µs) for which RF is granted to CoEx before it is passed back to WLAN16xx
WLAN QuotaThe duration (in µs) for which RF is granted to WLAN before it is passed back to CoEx16xx

(x): required if “Simultaneous RX Access”/Combined mode is enabled

Depending on the PTA mode and if the combined mode is enabled, all settings are not applicable. You can refer to the PTA mode columns in the table above to know if a setting applies in a specific PTA mode.

In addition to the information provided in this table, the timings settings are shown on the chronograms below. All the timings have as a reference the CoEx request (t = 0) except for the “Periodic TX RX Sampling Time” which has its reference from “First Slot time”. Rules and links between timings are listed below. If not followed, the WF(M)200 overwrites erroneous/impossible timing settings. The following assertions must be followed:

In addition to following the rules above, those timings have also to match the CoEx timings. In the chronograms below, a standard CoEx request is shown and the PTA wires are represented as well as the CoEx TX, CoEx RX, FEM TX and FEM RX signals (FEM implying the WLAN interface).

PTA Signal Chronogram using PTA 3-Wire Combined

3w timings sequence

PTA Signal Chronogram using PTA 4-Wire Combined

4w timings sequence

PTA State Request

The PTA state Request allows the application host to enable or disable the PTA mechanism. It can be dynamically called by the host. The PTA is disabled by default after a WF(M)200 reset.

While the PTA state is on, the two other PTA requests (priority and settings) cannot be issued to the WF(M)200. The host needs to disable the PTA to send those requests.

PTA Software Implementation

Silicon Labs provides two ways to interact with the WF(M)200 Wi-Fi transceiver. A first solution is based on the LMAC API and is meant for powerful application hosts (e.g., Linux hosts) already embedding an Upper MAC layer. The second solution in based on the FMAC API and is designed for memory constrained application hosts (e.g., microcontroller hosts). To access the PTA APIs described in the PTA Firmware Requests section, each solution provides its own interface.

Using the PTA API with the LMAC Driver

The PTA configuration on a Linux host using the LMAC API relies on the Linux driver and a dedicated PTA Python module:

The first step is to run the Linux driver on your platform, initialize the WF(M)200 and send a PDS with the PTA GPIOs enabled (cf. PTA GPIOs Configuration through the PDS). Finally, use the PTA Python tools to configure the PTA on the WF(M)200. Refer to the associated README.md files to get started with both resources.

Using the PTA API with the FMAC Driver

The PTA configuration on a microcontroller using the FMAC API relies on the Wi-Fi FMAC driver. The FMAC driver is available on a GitHub repository: https://github.com/SiliconLabs/wfx-fullMAC-driver It exposes 3 functions tied with the WF(M)200 firmware APIs:

Those C functions are used by the host application to configure the PTA mechanism. Here are the steps to follow to be able to call those APIs:

WF200 Configuration Setup for Different Coexistence Applications

Example 1: WF(M)200 - EFR32 running BLE - 3-Wire PTA - Balanced Priority

In this example, the WF(M)200 PTA is configured to operate with a single BLE EFR32 using 3-Wire PTA mode. The example uses a balanced arbitration between the two radios (i.e., PTA_PRIORITY_BALANCED).

Using the Wi-Fi FMAC Driver

status = sl_wfx_pta_settings(SL_WFX_PTA_3W,          //PTA Mode: 3-Wire
                             SL_WFX_SIGNAL_HIGH,     //Request Signal Active Level: high
                             SL_WFX_SIGNAL_HIGH,     //Priority Signal Active Level: high
                             SL_WFX_SIGNAL_HIGH,     //Freq Signal Active Level: not used
                             SL_WFX_SIGNAL_LOW,      //Grant Signal Active Level: low
                             SL_WFX_COEX_TYPE_BLE,   //CoEx type : BLE
                             SL_WFX_GRANT,           //Default Grant State: granted
                             0,                      //Simultaneous RX: false
                             10,                     //Priority Sampling Time: 10 µs
                             0,                      //TX/RX Sampling Time: NA
                             0,                      //Freq Sampling Time: NA
                             72,                     //Grant Valid Time: 72 µs
                             140,                    //FEM Control Time: 140 µs
                             0,                      //First Slot Time: NA
                             0,                      //Periodic TX/RX Sampling Time: NA
                             0,                      //CoEx Quota: NA
                             0);                     //WLAN Quota: NA
if(status == SL_STATUS_OK)
{
  printf("PTA settings configured\r\n");
}else{
  printf("PTA settings command error\r\n");
}

In this example, the PTA settings are configured for a BLE CoEx device connected to 3 PTA wires (Request, Grant, Priority). In this 3-Wire PTA mode, only the Priority sampling, Grant valid and FEM control times apply (respectively 10 µs, 72 µs and 140 µs). Those timings are dependent on the PTA CoEx configuration as well.

status = sl_wfx_pta_state(SL_WFX_PTA_ON); //Turn the PTA ON
if(status == SL_STATUS_OK)
{
  printf("PTA Enabled\r\n");
}else{
  printf("PTA Command error\r\n");
}

The PTA mechanism is active and starts granting the CoEx requests if the RF medium is not used by the Wi-Fi interface or the CoEx requests have a higher priority.

Using the Wi-Fi Linux Driver

Similarly, there are the steps to configure the PTA in the configuration 3-Wire PTA mode/balanced priority on a Linux platform.

>>> dut.settings('--pta_mode 3w                       //PTA Mode: 3-Wire
                  --request_signal_active_level high  //Request Signal Active Level: high
                  --priority_signal_active_level high //Priority Signal Active Level: high
                  --grant_signal_active_level low     //Grant Signal Active Level: low
                  --coex_type ble                     //CoEx type : BLE
                  --default_grant_state grant         //Default Grant State: granted
                  --simultaneous_rx_accesses false    //Simultaneous RX: false
                  --priority_sampling_time 10         //Priority Sampling Time: 10 µs
                  --grant_valid_time 72               //Grant Valid Time: 72 µs
                  --fem_control_time 140              //FEM Control Time: 140 µs
                  ')

Below the line to be copy-pasted.

>>> dut.settings('--pta_mode 3w --request_signal_active_level high --priority_signal_active_level high --grant_signal_active_level low --coex_type ble --default_grant_state grant --simultaneous_rx_accesses false --priority_sampling_time 10 --grant_valid_time 72 --fem_control_time 140')

In this example, the PTA settings are configured for a BLE CoEx device connected to 3 PTA wires (Request, Grant, Priority). In this 3-Wire PTA mode, only the Priority sampling, Grant valid and FEM control times apply (respectively 10 µs, 72 µs and 140 µs). Those timings are dependent on the PTA CoEx configuration as well.

The PTA mechanism is active and starts granting the CoEx requests if the RF medium is not used by the Wi-Fi interface or the CoEx requests have a higher priority.

Example 2: WF(M)200 - EFR32 running ZigBee - 4-Wire PTA - CoEx High Priority

In this example, the WF(M)200 PTA is configured to operate with a single ZigBee EFR32 using 4-Wire PTA mode. The example uses an arbitration favoring the CoEx interface (i.e., PTA_PRIORITY_COEX_HIGH).

Using the Wi-Fi FMAC Driver

It is considered that the configuration steps of "Example 1: WF(M)200 - EFR32 running BLE - 3-Wire PTA - Balanced Priority" have already been applied.

status = sl_wfx_pta_priority(SL_WFX_PTA_PRIORITY_COEX_HIGH); //Set PTA priority to COEX_HIGH
if(status == SL_STATUS_OK)
{
  printf("PTA priority configured\r\n");
}else{
  printf("PTA priority command error\r\n");
}
status = sl_wfx_pta_settings(SL_WFX_PTA_4W,           //PTA Mode: 4-Wire
                             SL_WFX_SIGNAL_HIGH,      //Request Signal Active Level: high
                             SL_WFX_SIGNAL_HIGH,      //Priority Signal Active Level: high
                             SL_WFX_SIGNAL_HIGH,      //Freq Signal Active Level: high
                             SL_WFX_SIGNAL_LOW,       //Grant Signal Active Level: low
                             SL_WFX_COEX_TYPE_GENERIC,//CoEx type : generic
                             SL_WFX_GRANT,            //Default Grant State: granted
                             1,                       //Simultaneous RX: true
                             10,                      //Priority Sampling Time: 10 µs
                             15,                      //TX/RX Sampling Time: 15 µs
                             15,                      //Freq Sampling Time: 15 µs
                             20,                      //Grant Valid Time: 20 µs
                             21,                      //FEM Control Time: 21 µs
                             20,                      //First Slot Time: 20 µs
                             5,                       //Periodic TX/RX Sampling Time: 5 µs
                             0,                       //CoEx Quota: NA
                             0);                      //WLAN Quota: NA
if(status == SL_STATUS_OK)
{
  printf("PTA settings configured\r\n");
}else{
  printf("PTA settings command error\r\n");
}

In this example, the PTA settings are configured for a ZigBee CoEx device connected to the 4 PTA wires (Request, Grant, Priority, Freq). In this 4-Wire PTA mode, all the timing configurations apply. The simultaneous mode is enabled thus the PTA allows both the CoEx and the Wi-Fi to receive at the same time. The PTA is informed by the PRIORITY signal about the CoEx request directionality. In one request, the CoEx directionality can change and affect the PTA arbitration. Settings “TX/RX Sampling Time”, “First Slot Time” and “Periodic TX/RX Sampling Time” are involved in sampling the directionality information on the PRIORITY signal (cf. PTA Settings Requests).

In addition, the “FEM Control Time” is set as close as possible to the “Grant Valid Time” to allow the ZigBee device to take the RF medium quickly after the PTA has granted a CoEx request. This is motivated by the fact that unlike BLE, the ZigBee protocol requires a CCA (Clear Channel Assessment) period before transmitting. Here again, those timings are dependent on the PTA CoEx configuration as well.

status = sl_wfx_pta_state(SL_WFX_PTA_ON); //Turn the PTA ON
if(status == SL_STATUS_OK)
{
  printf("PTA Enabled\r\n");
}else{
  printf("PTA Command error\r\n");
}

The PTA mechanism is active and starts granting the CoEx requests if the RF medium is not used by the Wi-Fi interface or the CoEx requests have a higher priority.

Using the Wi-Fi Linux Driver

The assumption is that the configuration steps of “Example 1: WF(M)200 - EFR32 running BLE - 3-Wire PTA - Balanced Priority” have already been applied.

>>> dut.priority('--priority_mode coex_high') //Set PTA priority to coex_high
>>> dut.settings('--pta_mode 4w                       //PTA Mode: 4-Wire
                  --request_signal_active_level high  //Request Signal Active Level: high
                  --priority_signal_active_level high //Priority Signal Active Level: high
                  --freq_signal_active_level high     //Freq Signal Active Level: high
                  --grant_signal_active_level low     //Grant Signal Active Level: low
                  --coex_type generic                 //CoEx type: generic
                  --default_grant_state grant         //Default Grant State: granted
                  --simultaneous_rx_accesses true     //Simultaneous RX: true
                  --priority_sampling_time 10         //Priority Sampling Time: 10 µs
                  --tx_rx_sampling_time 15            //TX/RX Sampling Time: 15 µs
                  --freq_sampling_time 15             //Freq Sampling Time: 15 µs
                  --grant_valid_time 20               //Grant Valid Time: 72 µs
                  --fem_control_time 21               //FEM Control Time: 140 µs
                  --first_slot_time 20                //First Slot Time: 20 µs
                  --periodic_tx_rx_sampling_time 5    //Periodic TX/RX Sampling Time: 5 µs
                  ')

Below the line to be copy-pasted.

>>> dut.settings('--pta_mode 4w --request_signal_active_level high --priority_signal_active_level high --freq_signal_active_level high --grant_signal_active_level low --coex_type generic --default_grant_state grant --simultaneous_rx_accesses true --priority_sampling_time 10 --tx_rx_sampling_time 15 --freq_sampling_time 15 --grant_valid_time 20 --fem_control_time 21 --first_slot_time 20 --periodic_tx_rx_sampling_time 5')

In this example, the PTA settings are configured for a ZigBee CoEx device connected to the 4 PTA wires (Request, Grant, Priority, Freq). In this 4-Wire PTA mode, all the timing configurations apply. The simultaneous mode is enabled thus the PTA allows both the CoEx and the Wi-Fi to receive at the same time. The PTA is informed by the PRIORITY signal about the CoEx request directionality. In one request, the CoEx directionality can change and affect the PTA arbitration. Settings “TX/RX Sampling Time”, “First Slot Time” and “Periodic TX/RX Sampling Time” are involved in sampling the directionality information on the PRIORITY signal (cf. PTA Settings Requests).

In addition, the “FEM Control Time” is set as close as possible to the “Grant Valid Time” to allow the ZigBee device to take the RF medium quickly after the PTA has granted a CoEx request. This is motivated by the fact that unlike BLE, the ZigBee protocol requires a CCA (Clear Channel Assessment) period before transmitting. Here again, those timings are dependent on the PTA CoEx configuration as well.

The PTA mechanism is active and starts granting the CoEx requests if the RF medium is not used by the Wi-Fi interface or the CoEx requests have a higher priority.

Example 3: WF(M)200 - EFR32 running BLE - 2-Wire PTA - WLAN Maximized Priority

In this example, the WF(M)200 PTA is configured to operate with a single BLE EFR32 using 2-Wire PTA mode. The example uses an arbitration maximizing the Wi-Fi access to the RF medium (i.e., PTA_PRIORITY_WLAN_MAXIMIZED).

Using the Wi-Fi FMAC Driver

The assumption is that the configuration steps of “Example 1: WF(M)200 - EFR32 running BLE - 3-Wire PTA - Balanced Priority” have already been applied.

status = sl_wfx_pta_priority(SL_WFX_PTA_PRIORITY_WLAN_MAXIMIZED); //Set PTA priority to WLAN_MAXIMIZED
if(status == SL_STATUS_OK)
{
  printf("PTA priority configured\r\n");
}else{
  printf("PTA priority command error\r\n");
}
status = sl_wfx_pta_settings(SL_WFX_PTA_2W,           //PTA Mode: 2-Wire
                             SL_WFX_SIGNAL_HIGH,      //Request Signal Active Level: high
                             SL_WFX_SIGNAL_HIGH,      //Priority Signal Active Level: not used
                             SL_WFX_SIGNAL_HIGH,      //Freq Signal Active Level: not used
                             SL_WFX_SIGNAL_LOW,       //Grant Signal Active Level: low
                             SL_WFX_COEX_TYPE_BLE,    //CoEx type : BLE
                             SL_WFX_GRANT,            //Default Grant State: granted
                             0,                       //Simultaneous RX: NA
                             0,                       //Priority Sampling Time: NA
                             0,                       //TX/RX Sampling Time: NA
                             0,                       //Freq Sampling Time: NA
                             0,                       //Grant Valid Time: NA
                             0,                       //FEM Control Time: NA
                             0,                       //First Slot Time: NA
                             0,                       //Periodic TX/RX Sampling Time: NA
                             7500,                    //CoEx Quota: 7500 µs
                             15000);                  //WLAN Quota: 15000 µs
if(status == SL_STATUS_OK)
{
  printf("PTA settings configured\r\n");
}else{
  printf("PTA settings command error\r\n");
}

In this example, the PTA settings are configured for a BLE CoEx device connected to 2 PTA wires (Request, Grant). In this 2-Wire PTA mode, a quota mechanism is used to share the RF medium. If no request is issued by the CoEx device, the Wi-Fi interface has the medium for 15000 µs. After this period, the access is granted to the CoEx for 7500 µs. if a request is issued by the CoEx and no WLAN action is on-going, the PTA allows the CoEx to access the RF medium. In case of a WLAN request, the WLAN request is given priority over an on-going CoEx action and is protected for the action duration.

status = sl_wfx_pta_state(SL_WFX_PTA_ON); //Turn the PTA ON
if(status == SL_STATUS_OK)
{
  printf("PTA Enabled\r\n");
}else{
  printf("PTA Command error\r\n");
}

The PTA mechanism is active and starts sharing the RF medium using the quotas provided.

Using the Wi-Fi Linux Driver

The assumption is that the configuration steps of “Example 1: WF(M)200 - EFR32 running BLE - 3-Wire PTA - Balanced Priority” have already been applied.

>>> dut.priority('--priority_mode wlan_maximized') //Set PTA priority to wlan_maximized
>>> dut.settings('--pta_mode 2w                       //PTA Mode: 2-Wire
                  --request_signal_active_level high  //Request Signal Active Level: high
                  --grant_signal_active_level low     //Grant Signal Active Level: low
                  --coex_type ble                     //CoEx type: BLE
                  --default_grant_state grant         //Default Grant State: granted
                  --coex_quota 7500                   //CoEx Quota: 7500 µs
                  --wlan_quota 15000                  //WLAN Quota: 15000 µs
                  ')

Below the line to be copy-pasted.

>>> dut.settings('--pta_mode 2w --request_signal_active_level high --grant_signal_active_level low --coex_type ble --default_grant_state grant --coex_quota 7500 --wlan_quota 15000')

In this example, the PTA settings are configured for a BLE CoEx device connected to 2 PTA wires (Request, Grant). In this 2-Wire PTA mode, a quota mechanism is used to share the RF medium. If no request is issued by the CoEx device, the Wi-Fi interface has the medium for 15000 µs. After this period, the access is granted to the CoEx for 7500 µs. if a request is issued by the CoEx and no WLAN action is on-going, the PTA allows the CoEx to access the RF medium. In case of a WLAN request, the WLAN request is given priority over an on-going CoEx action and is protected for the action duration.

The PTA mechanism is active and starts sharing the RF medium using the quotas provided.