AN1017: Zigbee® and OpenThread
Coexistence with Wi-Fi®
This application note describes methods to improve coexistence of
2.4 GHz IEEE 802.11b/g/n Wi-Fi and IEEE 802.15.4-based radios
such as Zigbee® and OpenThread. This application note assumes
you have a basic understanding of the concepts and principles of
Wi-Fi coexistence with 802.15.4 radios and how Wi-Fi coexistence
is implemented on EFR32 devices. For more information, see
UG103.17: Wi-Fi® Coexistence Fundamentals.
This application note describes EFR32 Zigbee and OpenThread coexistence support for
EmberZNet PRO 6.9.0.0 and OpenThread 1.1.0.0. See 5 Document Revision History for
a summary of key changes in previous revisions of this application note.
For additional details about the implementation of managed coexistence are included in
AN1243: Timing and Test Data for EFR32 Coexistence with Wi-Fi, available under nondisclosure from Silicon Labs Sales.
KEY POINTS
•Configure Wi-Fi coexistence for Zigbee
(AppBuilder) and OpenThread (the Component Editor).
•Use coexistence CLI commands for
Zigbee and OpenThread.
•Order the Coexistence Backplane Evalu-
ation Board.
silabs.com | Building a more connected world. Rev. 2.3
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
5. Document Revision History .................................................................................................................. 33
silabs.com | Building a more connected world. Rev. 2.3 | 2
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Introduction
1. Introduction
This application note includes the following sections:
•2 Configuring Wi-Fi Coexistence describes how to configure the Silicon Labs Packet Traffic Arbitration (PTA) using AppBuilder for
Zigbee and the Simplicity Studio
®
(SSv5) Component Editor for OpenThread.
• 3 Coexistence CLI Commands describes how to use Command Line Interface (CLI) commands for Zigbee and OpenThread.
• 4 Coexistence Backplane Evaluation Board (EVB) explains how to order the EVB for evaluating the Silicon Labs EFR32 software
coexistence solution and introduces the Silicon Labs Wi-Fi Coexistence Learning Center.
silabs.com | Building a more connected world. Rev. 2.3 | 3
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
2. Configuring Wi-Fi Coexistence
2.1. PTA Software Setup with AppBuilder (Zigbee)
GPIO interrupt numbers are based on the GPIO pin numbers and not the port. This can cause conflicts if the same pin is selected for
different ports—for example, SPI_CS on PB01 will conflict with GRANT on PC01 because they will both have 1 as an interrupt number.
Silicon Labs recommends avoiding these conflicts. If the conflict exists in hardware, you can add the following coexistence macros in the
Additional Macros section of the Simplicity IDE tab:
• BSP_COEX_GNT_INTNO
• BSP_COEX_PRI_INTNO
• BSP_COEX_PWM_REQ_INTNO
• BSP_COEX_REQ_INTNO
• BSP_COEX_RHO_INTNO
Use the Configurator DefaultMode PORTIO map as a guide to determine which interrupt number to use in the Additional Macros Value
column by avoiding port pin numbers in use by other GPIO interrupts.
The steps to set up PTA Software for Zigbee using AppBuilder are described below. These steps assume you have installed Simplicity
Studio 5 and the EmberZNet SDK (Software Development Kit) and that you have a project open in the Simplicity IDE (Integrated Development Environment).
1. Select the RadioCoexistence plugin under the RAIL section of the Plugins tab. Under the Utility section selecting the Radio Coex-
istence CLI plugin is optional but recommended.
Figure 2-1. Install Radio Coexistence Plugin
2. Open the project’s .hwconf file in Hardware Configurator and select Default Mode Peripherals view.
3. Select Coexistence in the Radio section to open coexistence properties and ensure Coexistence is enabled.
silabs.com | Building a more connected world. Rev. 2.3 | 4
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
Figure 2-2. Radio Coexistence Hardware Configurator
AppBuilder displays the Properties of Coexistence as shown in the following figure.
silabs.com | Building a more connected world. Rev. 2.3 | 5
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
Figure 2-3. Properties of Coexistence in AppBuilder
2.2. PTA Software Setup with the Component Editor (OpenThread)
The steps to set up PTA Software for OpenThread using the Component Editor are described below .These steps assume you
have installed Simplicity Studio 5 and the OpenThread SDK and that you have a project open in the Simplicity IDE.
1. On the SOFTWARE COMPONENTS tab, search for coex in the ‘component’s name’ search field (at the top right).
2. Under Platform components, select the RAIL Utility Coexistence component and click Install as shown in the following figure.
silabs.com | Building a more connected world. Rev. 2.3 | 6
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
Figure 2-4. Install RAIL Utility, Coexistence
3. Once the Coexistence component is successfully installed, click Configure or the configure symbol next to the component name to
open the coexistence properties as shown in the following figure.
Figure 2-5. Configure RAIL Utility, Coexistence
The following figure shows the different coexistence properties in the Component Editor. For more information on coexistence properties,
see 2.3 Coexistence Configurations.
silabs.com | Building a more connected world. Rev. 2.3 | 7
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
Figure 2-6. Coexistence Properties in the Component Editor
silabs.com | Building a more connected world. Rev. 2.3 | 8
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
2.3. Coexistence Configurations
The following subsections describe the coexistence configurations in detail.
Note: To configure GPIO pins for a coexistence signal in the Component Editor, use the equivalent SL_RAIL_UTIL_COEX <signal>
section of the configuration header.
2.3.1. REQUEST
REQUEST signal enabled
• If selected, REQUEST is mapped to GPIO pin and is used by PTA implementation.
• If not selected, REQUEST is not mapped to GPIO pin.
REQUEST signal is shared
• If selected. REQUEST is shared and implements open-drain or open-source I/O for multi-EFR32 radio applications.
• If active low, REQUEST is open-drain and an external 1 kΩ ±5% pull-up is required.
• If active high, REQUEST is open-source and an external 1 kΩ ±5% pull-down is required.
• If not selected, REQUEST is not shared and implements a push-pull output for single EFR32 radio applications.
REQUEST signal active high
• If selected, REQUEST GPIO pin is driven high (> Voh) when REQUEST is asserted.
• If not selected, REQUEST GPIO pin is driven low (< Vol) when REQUEST is asserted.
REQUEST signal GPIO port and REQUEST signal GPIO pin
• Select REQUEST port and pin matching circuit board configuration.
• To configure GPIO port and pin for the REQUEST signal in the Component Editor, use the SL_RAIL_UTIL_COEX_REQ section of
the configuration header.
Figure 2-7. REQUEST signal in the Component Editor
REQUEST signal max backoff mask [0-255]
• REQUEST signal max backoff determines the random REQUEST delay mask (only valid if REQUEST signal is shared).
• Random delay (in µs) is computed by masking the internal random variable against the entered mask.
n
• The mask should be set to a value of 2
-1 to insure a continuous random delay range.
2.3.1.1. Receive Retry
Receive retry REQUEST enabled
• If selected, REQUEST is held after a corrupted receive packet or after a successful receive packet with GRANT denied until timeout
expires or another packet is received.
Note: This feature is useful to hold 2.4 GHz band clear while the remote device re-transmits a packet, maximizing the opportunity
to receive an uncorrupted retry packet from the remote device, reducing 2.4 GHz RF traffic and improving battery life.
•If not selected, REQUEST is not held after a corrupted receive packet or after a successful receive packet with GRANT denied.
silabs.com | Building a more connected world. Rev. 2.3 | 9
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
Receive retry timeout (milliseconds) [0-255]
• Selects the timeout for REQUEST hold after a corrupted receive packet.
Notes:
1. 16ms is recommended to allow for maximum 802.15.4 packet duration and MAC retry random delay.
2. Many Wi-Fi/PTA implementations have a maximum GRANT timeout, which should be set to received retry timeout plus 6ms to allow
for maximum size corrupted packet, maximum random delay, and maximum size retry packet.
REQUEST high PRIORITY on receive retry
•If selected, PRIORITY is asserted during REQUEST hold after a corrupted receive packet or after a successful receive packet with
GRANT denied.
•If not selected, PRIORITY is deasserted during REQUEST hold after a corrupted receive packet or after a successful receive packet
with GRANT denied.
2.3.2. GRANT
GRANT signal enabled
• If selected, GRANT is mapped to GPIO pin and is used by PTA implementation.
• If not selected, GRANT is not mapped to GPIO pin and GRANT is always asserted.
GRANT signal active high
• If selected, GRANT is asserted when GRANT GPIO pin is high (> Vih).
• If not selected, GRANT is asserted when GRANT GPIO pin is low (< Vil).
GRANT signal GPIO port and GRANT signal GPIO pin
• Select GRANT port and pin matching circuit board configuration.
• To minimize PTA impact to other EFR32 peripherals, recommended GRANT port and pin are:
• To configure GPIO port and pin for the GRANT signal in the Component Editor, use the SL_RAIL_UTIL_COEX_GNT section of the
configuration header.
Figure 2-8. GRANT signal in the Component Editor
2.3.2.1. Abort Transmission Mid Packet If GRANT Is Lost
• If selected, losing GRANT during an 802.15.4 TX will abort the 802.15.4 TX.
• If not selected, losing GRANT after the initial evaluation at end of CCA will not abort the 802.15.4 TX.
Note: In the Component Editor, this option has been moved from the GRANT section to the common section of the configuration
header.
silabs.com | Building a more connected world. Rev. 2.3 | 10
AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
Configuring Wi-Fi Coexistence
2.3.2.2. ACK Disable
Disable ACKing when GRANT deasserted, RHO asserted, or REQUEST not secured (shared REQUEST only)
• If selected, the ACK to a valid RX packet, requiring an ACK, is not transmitted if GRANT is deasserted, RHO is asserted, or REQUEST
is not secured (shared REQUEST only).
Note: This feature allows completing an 802.15.4 message, regardless of PTA signals, to minimize additional retries from remote
device, reducing 2.4 GHz RF traffic and improving battery life.
• If not selected, the ACK to a valid RX packet requiring an ACK is transmitted regardless of GRANT, RHO, or REQUEST state.
Note: In the Component Editor, this option has been moved from the GRANT section to the common (IEEE802.15.4 Only Configura-
tion) section of the configuration header.
Figure 2-9. Abort Tx mid-packet and Ack Disable options in the Component Editor
2.3.3. PRIORITY
PRIORITY signal enabled
• If selected, PRIORITY is mapped to GPIO pin and is used by PTA implementation.
• If not selected, PRIORITY is not mapped to GPIO pin.
PRIORITY signal active high
• If selected, PRIORITY GPIO pin is driven high (> Voh) when PRIORITY is asserted.
• If not selected, PRIORITY GPIO pin is driven low (< Vol) when PRIORITY is asserted.
• If Enable Directional PRIORITY equals True, PRIORITY assert signal level must be set to High.
PRIORITY signal GPIO port and PRIORITY signal GPIO pin
• Select PRIORITY port and pin matching circuit board configuration.
• To configure GPIO port and pin for the PRIORITY signal in the Component Editor, use the SL_RAIL_UTIL_COEX_PRI section of
the configuration header.
silabs.com | Building a more connected world. Rev. 2.3 | 11
Loading...
+ 25 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.