Zigbee and Thread Wireless Knowledge Base

Zigbee & Thread Knowledge Base

Publish

What are the valid values for txPower in EFR32 devices?

Verthika Varati | 11/329/2020 | 06:39 PM
The EFR32 families of chips each come equipped with multiple Power Amplifiers (PAs):
- EFR32xG1x
  
  A high-power * 2.4 GHz PA (for power 20 dBm and lower)**
  
  A low-power 2.4 GHz PA (for power 0 dBm and lower)
  
  A Sub-GHz PA**
- EFR32xG21
  
  A high-power 2.4 GHz PA (for power 20 dBm and lower)**
  
  A medium-power 2.4 GHz PA (for power 10 dBm and lower)
  
  A low-power 2.4 GHz PA (for power 0 dBm and lower)
- EFR32xG22
  
  A high-power 2.4 GHz PA (for power 6 dBm and lower)**
  
  A low-power 2.4 GHz PA (for power 0 dBm and lower)
Each of these PAs has a unique number of discrete “power levels”, which are simply abstractions of the different register settings that control the active PA. For each PA, the following power levels are available:
- EFR32xG1x
  
  High-power 2.4 Ghz: 0-252**
  
  Low-power 2.4 Ghz: 1-7
  
  Sub-GHz: 0-248
- EFR32xG21
  
  High-power 2.4 Ghz: 1-180**
  
  Medium-power 2.4 Ghz: 1-90
  
  Low-power 2.4 Ghz: 1-64
- EFR32xG22
  
  High-power 2.4 Ghz: 0-128**
  
  Low-power 2.4 Ghz: 0-15
*Note that the use of 'high', 'medium', and 'low' in the names of these PAs refers to power consumption, not power output. It is possible, for instance, to configure the high-power PA to transmit at a lower dBm output than the low-power PA.

**Maximum power/use of these PAs may be restricted by your specific OPN. Please see the data sheet for more details regarding your particular part.

For more details and to set custom power curves for your design, refer AN1127: Power Amplifier Power Conversion Functions in RAIL 2.x
Master Wireless Hardware Doc list for EFR32 Series 2 SoCs and Wireless Modules

Verthika Varati | 11/324/2020 | 11:13 PM
The purpose of this KBA is to organize all Wireless Hardware related specific/generic technical documents (application notes and KBAs) applicable to EFR32 Series 2 SoCs and Wireless modules in one place. The content is grouped into the following categories to make it easier to find what you are looking for.
- [A] EFR32 Series 2 Wireless Modules
- [B] EFR32 Series 2 Wireless SoCs
- [C] Generic (applicable to both SoCs and Modules)
  
  [1] RF
  
  [2] Certifications
  
  [3] Antenna
  
  [4] Coexistence
  
  [5] MCU
  
  [6] Testing
  
  [7] Other
[A] EFR32 Series 2 Wireless Modules:

Application Notes

AN1048: Regulatory RF Module Certifications

AN1223: LGA Manufacturing Guidance

KBAs

STEP File information and steps to obtain those files

Design and Assembly guidelines for SiPs

[B] EFR32 Series 2 Wireless SoCs:

AN0002.2: EFR32 Wireless Gecko Series 2 Hardware Design Considerations

AN0948.2: EFR32 Series 2 Power Configurations and DC-DC

AN933.2: EFR32 Series 2 Minimal BOM

AN930.2: EFR32 Series 2 2.4 GHz Matching Guide

AN928.2: EFR32 Series 2 Layout Design Guide

[C] Generic

[1] RF

KBAs

ESD protection of RF devices

RF Range calculator

RF Range factors

Range improvement calculation for a given extra link budget

Data rate, deviation, modulation index for 2GFSK signals

Modulation choice

OBW for digital modulations

Modulation index for digital modulations

RF shield vs. RX immunity

General layer count versus power output recommendations

Custom design PCB number of layers

Recommended routing technique for more layer RF designs

General RF layout suggestions

[2] Certifications

KBAs

Maximum allowed power for ZigBee applications under ETSI EN 300 328

ETSI EN 300 328 Adaptivity Compliance

FCC Harmonic Requirements

TX power limitations for regulatory compliance (ETSI, FCC)

Tips for FCC certification on Silicon Labs' 2.4GHz 802.15.4-based solutions

How to test and estimate TIS/TRP

[3] Antenna

Application Notes

AN1088: Designing with an Inverted-F 2.4 GHz PCB Antenna

APL10045: Antennas for Short Range Devices

AN853: Single-ended Antenna Matrix Design Guide

KBAs

Design tip for dipole antennas

Whip antenna length and size

Whip antenna parameters

Do loop antennas require a ground plane?

PCB antenna with wider bandwidth

Recommended distance between antennas for antenna diversity

Recommended external antenna matching network

How to maximize the isolation of coex. antennas on the same PCB

[4] Coexistence

AN1128: Bluetooth® Coexistence with Wi-Fi®

AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®

[5] MCU/Peripherals

Application Notes

AN958: Debugging and Programming Interfaces for Custom Designs

AN0016.2: Oscillator Design Considerations

KBAs

EFR32 DCDC powering external circuits

BSDL files

Layout design practices around DC-DC converter

CTUNE Access

HFXO Capacitor Bank (Ctune) calibration on EFR32

Saving CTUNE value as manufacturing token

[6] Testing

Application Notes

AN972: EFR32 RF Evaluation Guide

AN718: Manufacturing Test Overview

AN700.1: Manufacturing Test Guidelines for the EFR32

AN1162: Using the Manufacturing Library for EmberZNet

AN1046: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v2.x

AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x

UG409: RAILtest User’s Guide

AN1019: Using the NodeTest Application

AN961: Bringing Up Custom Devices for the EFR32MG and EFR32FG Families

KBAs

How to build and use the StandardizedRfTesting sample in EmberZnet SDK?

Implementing wireless direct test mode (DTM)

[7] Other

How do I determine the PCB and schematic version of kit boards?

BRD4001A WSTK dimension

Hardware Design Review submission expectations for EFR32MGxx based designs

What are the valid values for txPower?

How to find schematics and other documentation for radio boards?

Six Hidden Costs in a Wireless SoC Design
Master Wireless Hardware KBA list for EFR32 Series 1 SoCs and Wireless Modules

SunnyA | 10/304/2020 | 04:08 PM
This Knowledge Base Article (KBA) aims to organize all Wireless Hardware related technical documents and related individual KBAs for EFR32 Series 1 SoCs and Wireless modules together in one place.

The KBA organizes all technical documents into categories for a better and convenient way to refer to the contents while designing a custom application based on these parts. The categorized RF hardware contents are as follows:-

[A] EFR32 Series 1 Wireless Modules:

Application Notes:
- AN1048: Regulatory RF Module Certifications
- AN1223: LGA Manufacturing Guidance
- AN928.1: EFR32 Series 1 Layout Design Guide
- AN958: Debugging and Programming Interfaces for Custom Designs
- AN0016.1: Oscillator Design Considerations
- AN1088: Designing with an Inverted-F 2.4 GHz PCB Antenna
- AN1128: Bluetooth® Coexistence with Wi-Fi®
- AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
- INS12840: Case study for Z-Wave usage in the presence of LTE
Knowledge Base Articles:
[B] EFR32 Series 1 Wireless SOCs:

[1] Matching Networks

Application Notes:
- AN930.1: EFR32 Series 1 2.4 GHz Matching Guide
- AN923: EFR32 sub-GHz Matching Guide
- AN1180: EFR32 Series 1 sub-GHz Discrete Matching Solutions
- AN1275: Impedance Matching Network Architectures
- AN1081: Integrated Passive Devices for EFR32 Series 1 Sub-GHz RF Matching
Knowledge Base Articles:
[2] RF

Application Notes:
- AN928.1: EFR32 Series 1 Layout Design Guide
- AN933.1: EFR32 Series 1 Minimal BOM
Knowledge Base Articles:
[3] Antenna

Application Notes:
- AN1088: Designing with an Inverted-F 2.4 GHz PCB Antenna
- AN853: SINGLE-ENDED ANTENNA MATRIX DESIGN GUIDE
Knowledge Base Articles:
[4] MCU, Power Supply and Peripherals

Application Notes:
- AN0002.1: EFM32 and EFR32 Wireless Gecko Series 1 Hardware Design Considerations
- AN0948: EFM32 and EFR32 Series 1 Power Configurations and DC-DC
- AN0016.1: Oscillator Design Considerations
- AN958: Debugging and Programming Interfaces for Custom Designs
Knowledge Base Articles:
[6] Antenna Diversity

Knowledge Base Articles:
- Recommended distance between antennas in an antenna diversity application
- How can I implement antenna diversity for EFR32MG?
[7] General

Application Notes:
- AN1128: Bluetooth® Coexistence with Wi-Fi®
- AN1017: Zigbee® and Silicon Labs® Thread Coexistence with Wi-Fi®
- AN700.1: Manufacturing Test Guidelines for the EFR32
- AN1162: Using the Manufacturing Library for EmberZNet
- AN972: EFR32 RF Evaluation Guide
- APL10045: Antennas for Short Range Devices
- INS14284: Prepare for Z-Wave Certification Tests
Knowledge Base Articles:
Where can I find BSDL file for EFR32 Wireless Gecko devices?

satownse | 02/32/2018 | 02:51 PM

BSDL files do not exist for EFR32 devices, because there is no boundary-scan TAP in the EFR32. We do have the ARM SWJ-DP which handles JTAG/SWD based accesses to the debug port (DP).
Ways to tell ZigBee nodes to leave the network.

ADKates | 07/196/2016 | 09:31 PM

There are 3 ways to request a device to leave the network, although none of them are perfect in that they do not guarantee the result of having a device exit immediately, or to force it to stay out of the network in the future ("kicking out a device").

Here are some descriptions of the leave request methods with pros and cons.

1) Send ZDO Leave to ZR parent with ZED's EUI as target
-Pros: Will always succeed (if ZED is still in the child table of ZR and ZR is reachable) with response status, regardless of what ZED's polling rate is.
-Cons: If ZED isn't polling parent regularly, parent's NWK Leave command to child could time out before child gets it, and child gets erased anyway. When child polls next time, parent will tell him to leave and rejoin because it's an non-child end device, so that gets you back to before the ZDO Leave.

2) Send ZDO Leave to ZED with ZED's EUI (or all-zero EUI) as target
-Pros: ZDO response clearly indicates whether ZED received the leave request. No confusion as above with ZED accidentally being told to rejoin.
-Cons: If ZED isn't polling parent regularly, it won't receive this request, so sender needs to be careful about timing of sending the request. In older EmberZNet stack versions (4.6 through 5.4), a bug existed that would sometimes reject a ZDO Leave Request sent to an end device depending on who was the sender. In EmberZNet versions 5.6.0 and earlier, the ZED won't get a ZDO Leave Response out before it leaves the network, so the requester must rely on the APS ACK rather than the ZDO response to confirm receipt.

3) Send APS Remove Device command (emberSendRemoveDevice) to ZR parent with ZED's EUI as deviceToRemove.
-Pros: APS-authenticated (unlike ZDO messages), so devices (even SE devices) can't choose to ignore this, and it is harder to spoof because it requires APS encryption.
-Cons: Need long address of child and parent for the command. No APS ACK available for APS commands, so can't confirm receipt by the parent. Still may encounter problem where parent deletes child before the child knows it was removed, causing child to rejoin on next poll attempt. Can only be sent by Trust Center.

In general, we recommend a fallback system, such as trying 2 and falling back to 1 (or 3) if it doesn't work.
HA Sample Switch won't sleep correctly with EmberZNet 5.7.3 using EFR32 on WSTK

ADKates | 07/194/2016 | 03:57 PM

Question
I'm having trouble getting the processor to sleep using the HA Sample applications in 5.7.3.

Answer
The Utility > EEPROM plugin was left unchecked for the sample apps to allow the apps to be run on modules which do not contain EEPROM. Most of the EFR32/WSTK kit modules do contain EEPROM, so the plugin should be checked before building.

Additionally, in some EFR32/WSTK combinations, the board must be power cycled/reset after the first programming of the boardfor sleep to work.
Peripheral utilization on EFR32MG by EmberZNet stack

Yuping Xiao | 07/190/2016 | 08:34 PM
Question

What peripherals on EFR32MG is the EmberZNet stack using?
Answer

Minimum Requirements

Minimum requirements for proper EmberZNet stack operation are the following:

High Frequency Crystal Oscillator (HFXO) – Needed for high-precision timing on IEEE 802.15.4 MAC layer state machines. (Note: The EFR32 cannot run the radio off of HFRCO. HFXO is needed for high-precision timing on IEEE 802.15.4 MAC layer state machines.)

Real Time Counter/Calendar (RTCC) – Needed to drive millisecond-driven events and sleep timing for stack and application events. Requires either Low Frequency RC Oscillator (LFRCO) or Low Frequency Crystal Oscillator (LFXO) as a clock source.

Energy Management Unit (EMU) Temperature Change (TEMPCHANGE) – Needed to support proper operation over full operating temperature range.

Watchdog Timer (WDOG) – Needed for self-management of code to prevent infinite loops. Requires Ultra-Low Frequency RC Oscillator (ULFRCO) as clock source.

TIMER0 – Needed for microsecond precision delay logic.

Clock Management Unit (CMU) – Needed for setup of clock sources.

Nested Vector Interrupt Controller (NVIC) – Needed for interrupt management.

Cryptographic (CRYPTO) module – Required for stack-level security functions.

Additional Resource Usage

These MCU peripherals may be needed by EmberZNet HAL, or Application Framework, or bootloader under certain use cases.

USART0 – Used for serial interaction with serial bootloader or application’s serial command line interface (CLI) if present.

USART1 – Used for serial interaction with dataflash for bootloader.

LDMA (2 channels out of 8 available) – Used for serial communication.

SerialWire Output (SWO) – Used for debug printing output if desired.

Instruction Trace Macrocell (ITM) – Used for in-system debugging if desired.

Packet Trace Interface (PTI) –Used for capture of TX/RX packets if desired.
GPIOs used for the pre-built EFR32MG NCP images

Yuping Xiao | 05/133/2016 | 10:43 PM
Question
Which GPIOs are used on the EFR32MG NCP-UART and NCP-SPI?
Answer
For the pre-built NCP images we include in EmberZNet releases for EFR32MG1P132F256GM48 and EFR32MG1P232F256GM48 variants (included in our Mighty Gecko Wireless SoC Starter Kit):

NCP-UART:

PA0 – TXD

PA1 – RXD

PA2 – CTS

PA3 – RTS

NCP-SPI:

PC6 – MOSI

PC7 – MISO

PC8 – SCLK

PC9 – nCS

PD10 – nHOST_INT

PD11 – nWAKE

To access these signals on the WSTK board, connect the external host to the Expansion Header pins according to the table "Expansion Header Pinout" in UG151.
EM3xx 24MHz Crystal Tuning

Sumeet6 | 11/314/2015 | 02:52 PM

For proper operation of the EM3xx RF block, it is very important to minimize transmit frequency offset, as well as comply with the 802.15.4 specification of +/-40ppm. The frequency offset is adjusted through the txtone (carrier tone) transmit function, as the 24MHz main clock offset directly relates to the transmitter frequency offset.

Use a spectrum analyzer to measure the frequency offset of the carrier. Set the amplitude reference level higher than the expected output power of the device in order to avoid possible damage to test equipment. For ceramic balun designs, this would be +10dBm, while for PA designs +30dBm should work fine as an initial setting and can be adjusted according to the actual PA TX power maximum capability. Configure the radio to transmit a continuous unmodulated tone at 2445MHz by issuing the commands ‘setchannel 13’ and ‘txtone’ with the nodetest application installed on the device. Measure the frequency offset by selecting the frequency counter setting on the spectrum analyzer followed by a marker peak search. To determine the PPM of the frequency offset, use the following equation:

Channel offset PPM = (expected / (measured – expected)) * 1E6

The frequency offset needs to be improved by adjusting the crystal loading caps only if it appears it will not comply with the +/- 40 PPM 802.15.4 specification. The intent is to tune the frequency to be as close to the desired frequency as possible. Refer to AN700 section 2.6, Transmit Frequency test and KBA article EM35xx-24MHz Crystal Selection for additional information.

AN700.0: Manufacturing Test Guidelines for the EM35x
EM35x - Using Software to Measure VDD_PADS

wmpaull | 09/268/2015 | 06:31 PM

Question
How to measure the VDD_PADS voltage on the EM35x series chips?

Answer
The data sheet states "The regulator input voltage, VDD_PADS, cannot be measured using the general purpose ADC, but it can be measured through Ember software." The reason is because VDD_PADS is not one of the selectable analog inputs for the user-exposed ADC, but it is available on the internal CALADC. Hence we provide an API, halMeasureVdd() in the HAL library that does this (per hal/micro/cortexm3/adc.h):

/** @brief Measures VDD_PADS in millivolts at the specified sample rate

* Due to the conversions performed, this function takes slightly under 250us

* with a variation across successive conversions approximately +/-20mv of

* the average conversion.

*

* @return A measurement of VDD_PADS in millivolts.

*/ uint16_t halMeasureVdd(ADCRateType rate);

If VDD_PADS is being driven by a DC-to-DC converter, then the customer would probably want to route the battery voltage input to that also to an analog GPIO of their choice, perhaps voltage divided to meet analog input criteria, and measure that using the normal ADC.   There is an API to assist converting the ADC's reading to volts (per hal/micro/adc.h):

/** @brief Convert the raw register value (the unaltered value taken

* directly from the ADC's data register) into a signed fixed point value with

* units 10^-4 Volts. The returned value will be in the range -12000 to

* +12000 (-1.2000 volts to +1.2000 volts).

*

* @appusage Use this function to get a human useful value.

*

* @param value An uint16_t to be converted.

*

* @return Volts as signed fixed point with units 10^-4 Volts.

*/ int16_t halConvertValueToVolts(uint16_t value);

Zigbee & Thread Knowledge Base

[A] EFR32 Series 2 Wireless Modules:

[B] EFR32 Series 2 Wireless SoCs:

[C] Generic

[1] RF

[2] Certifications

[3] Antenna

[4] Coexistence

[5] MCU/Peripherals

[6] Testing

[7] Other

[A] EFR32 Series 1 Wireless Modules:

[B] EFR32 Series 1 Wireless SOCs:

[1] Matching Networks

[2] RF

[3] Antenna

[4] MCU, Power Supply and Peripherals

[6] Antenna Diversity

[7] General

Question

Answer

Question

Answer

Question

Answer

Question

Answer

Tags

Top Authors

Archives