Q. What is CHIP?
A: Project Connected Home over IP (CHIP) is a new Working Group within the Zigbee Alliance. This Working Group plans to develop and promote the adoption of a new connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet.

The main idea for the CHIP project is to simplify development for manufacturers and increase compatibility for consumers.

Q. How do you compare CHIP with other protocols such as Thread?
A: CHIP is an app-layer standard that works on top of IP-based protocols such as Thread. It's not a networking protocol itself. Please also refer to the OpenThread FAQ.

Q. What is involved in building the CHIP examples?
A: Explain the basic build environments at a high level; add the link again on the details:

The CHIP project can be built on

• Ubuntu 20.04 LTS
• macOS 10.15
• Debian 10 

 Instructions to setup the CHIP environment are provided on the Github page: https://github.com/project-chip/connectedhomeip/blob/master/docs/BUILDING.md 

Q. Does the lock example for CHIP enable PTI?
A: Yes, it is.

Q: How do I see the debug log on a CHIP device?

A: Logs are enabled by default on our examples over SWO. An RTT terminal is needed to view the logging output. To Disable the logs, remove the defined EFR32_LOG_ENABLED located in efr32_sdk.gni and rebuild the project. 

Q. Does Silicon Lab's Network Analyzer support decode the CHIP transactions?
A: Currently (in the G-SDK 3.1.0 release), we don't support it yet. Please check back later.

Q. What's the connection between CHIP tools and OTBR?
A: It is UDP. EFR32 CHIP communication is based on IPV6

Network Topology for CHIP Communication:

<CHIP-Tool>----------<OTBR>----------<CHIP-DEVICE>

Q. Can you point me to some CHIP examples?
A: CHIP examples are available on GitHub:  

EFR32 Door Lock Example: https://github.com/project-chip/connectedhomeip/tree/master/examples/lock-app/efr32

EFR32 Lighting Example: https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/efr32

Q. How to add another cluster into the CHIP light or door lock examples?

A: This can be done using the ZAP configurator. Refer to: https://github.com/project-chip/zap 

Q: How to use Bluetooth in CHIP? 

A: As of now, Bluetooth is only used for commissioning CHIP device with OTBR. For BLE Commissioning, first, you need to build the Android app, and then with the app, you scan the QR code on the LCD screen on the WSTK. This will provide the App with the needed information to find and connect through BLE to our device. It starts the Secure Rendez-vous exchange with SPAKE2+. Once the secure key is created the app sends the OT provision to the device. The device starts a thread with those network info and joins the network. It will then send the global IP it received back to the phone.

This article contains some frequently asked questions and answers about Thread, its underlying technologies, and its implementation OpenThread. 

Q: What is Thread?

A: Open IP based Secure mesh networking protocol for IoT devices.

• Based on 802.15.4 in PHY/MAC layers but fundamentally different from other Mesh protocols such as BLE Mesh or Zigbee. 
• Thread uses 6LoWPAN to transmit IPv6 packets over 802.15.4 radios. In the NWK layer Thread can utilize IP routing and UDP. 
• Thread is secure since all devices in the Thread network have to use encrypted communications and all devices are authenticated. 
• Thread uses a commissioning solution to simplify network deployment. 
• Low-power thread devices can run from battery power for years.

Q: Is there a Thread specification?

Thread is specified by the members of the Thread Group. The specification is available upon request at https://www.threadgroup.org/ThreadSpec

Q: What is Thread commissioning?

A: Thread standardized the way commissioning should work. This requires a dedicated device role to be accessible by the Thread network. This device is the commissioner. 

The commissioner has a list of device credentials that are allowed to join the thread mesh. Joiner devices that have these credentials must authenticate themselves with the commissioner to be able to join. 

Commissioners can be part of the thread mesh or external devices communicating with the thread mesh through a border router. 

More info on commissioning in open-thread: https://openthread.io/guides/build/commissioning

Q: What is the RCP how is it different from an NCP?

A: While in the NCP design the core stack lives on the SoC this variant of the NCP design allows the core of OpenThread to live on the host processor with only a minimal MAC layer "controller" on the SoC with the Thread radio. The host processor typically doesn’t sleep in this design, in part to ensure the reliability of the Thread network. The advantage here is that OpenThread can utilize the resources on the more powerful processor.

More info can be found at https://openthread.io/platforms#platform_designs

Q: What is an IPv6 prefix and why do we care about it?

A: IP and consequently IPv6 prefixes define the valid address ranges of IP-based networks by setting the number of given bits indicated by, /8 - /16 - /64 - etc., to a fixed value from the 128-bit address value. 

Example: Given the following prefix: 2000::/8 We know that the first 8 bits of the IPv6 addresses will always be: 0010 0000 (x20) which gives us the IP address range of: 2000:0000:0000:0000:0000:0000:0000:0000 - 20ff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

It is recommended to ramp up on IPv6 which is described by the rfc2460 IETF standard before ramping up on Thread. 

More info on OT addresses can be found at https://openthread.io/guides/thread-primer/ipv6-addressing

Q. Can a Thread network have multiple Leader devices?
A: Thread networks have only one Leader device at any given time but this leader device can dynamically change according to network needs and changes. 

Q. What is the theoretical maximum of Thread devices in a single mesh network?

A: Thread supports 1 leader 32 routers and 511 end devices/routers. This means a theoretical maximum of 16385 devices in a single thread mesh network. 

Q: What's the master key?

A: The knowledge of the master key allows the decryption of all network traffic inside a Thread mesh network. 

It is mostly a randomly chosen 16-byte key that is usually shared with joining devices through the commissioning process or other out of band methods. 

Q: What is the joiner passphrase? 

A: The Joiner Passphrase or Joining Device Credential is a human-scaled passphrase for authenticating the new Joiner Device. 

This passphrase is used to establish a secure session between the Commissioner and Joiner. It is usually shared with the commissioner using an out-of-band method.

Details: Length: 6-32 characters, encoding: base32-thread (0-9,A-Y excluding I,O,Q and Z for readability)

Q: Is the PSKd different from the Joiner Device Credential?

A: The Joiner Device Credential is referred to as the PSKd or Pre-Shared Key for the Device when specifically encoded in binary form. 

Q: What is the PSKc?

A: Pre-Shared Key for the Commissioner is a derived key based on the commissioning credential which is used to establish the Commissioner Session. 

Used to establish a secure session with a Border Agent. All devices in the Thread network store the PSKc. 

Q: What is OpenThread?

A: This is an open-source implementation of Thread®. Google has released OpenThread to make the networking technology used in Google Nest products more broadly available to developers, in order to accelerate the development of products for the connected home and commercial buildings.

Q: Where can I get the OpenThread stack?

A: You can either get the OpenThread SDK as part of the Gecko SDK using Simplicity Studio V5 and it's built-in package manager OR get the raw OpenThread stack via Github: https://github.com/openthread/openthread.git

Q: What is the best way to start developing an OT application using Silicon Labs IC?

A: With Simplicity Studio 5, you can start with our project examples sleepy-demo-ftd / sleepy-demo-mtd. These examples are part of a 2 device demo where the sleepy-demo-ftd acts as a leader and the sleepy-demo-mtd joins the network as a Sleepy End Device.

Or if you prefer you can also run the OpenThread example projects using our SDK: (ot-cli-ftd, ot-cli-mtd, etc... )

Q: How do I do OTA in OpenThread?

A: OTA is not defined as part of OpenThread since Thread is a networking protocol, and OTA is an app-level feature. 

Q. Does OTBR support MQTT?
A: Yes. Check out the OTBR example configuration with MQTT at https://github.com/osaether/otbr-mqtt-sn/blob/master/README.md

Q. Can we have a list of all devices and their roles in the thread network? 

A: This topic deserves its own article but the short answer is: The tools in the Thread network exist to map out such a list to some extent but there is no single command from a single node that can do this. 

Q. Does OpenThread support use with the Apple HomeKit?
A: Yes. 

Q. If there is no border router, then the devices can't get a global address, right?
A: The Border Router is required for Global IPv6 addresses in the Thread network. 

The packet handoff functionality allows the application to get access to Zigbee messages at different stages of their journey through the Zigbee stack. The main use for this is debugging, but with the ability to drop, mangle or otherwise modify a packet, a range of custom behavior can be achieved. Furthermore erroneous or otherwise unwanted messages can be dropped or mangled prior to them being processed by the stack.

With the release of our Gecko SDK 3.1 (EmberZNet 6.9.0) the already existing packet handoff functionality of EmberZNet has been extended. As before the packet handoff functionality is accessible via the packet handoff plugin and allows both incoming as well as outgoing packets of different types to be caught by the application. For specific packets it is possible to drop, mangle or perform other actions on the packet under control of the application. 

Warning: Dropping, mangling or otherwise interfering with incoming or outgoing packets may affect Zigbee compliance and interoperability with other Zigbee certified devices. This is for expert users to be used with great care.

How to enable

The Packet Handoff plugin can be enabled from the plugins tab of the appbuilder, located under Utility. You can search for the term 'Packet' for quicker access. When selected, it offers options to allow all or different types of Zigbee or raw 15.4 packets which can be selected using the checkboxes. Additionally you also provide a buffer size to store the flat packet buffers.

APIs

When including the packet handoff plugin, it is possible to select which of the packet types described further down will be handed to the following two callbacks:

EmberPacketAction emberAfIncomingPacketFilterCallback(EmberZigbeePacketType packetType,

                                                      uint8_t *packetData,

                                                      uint8_t *size,

                                                      void *data);

   

EmberPacketAction emberAfOutgoingPacketFilterCallback(EmberZigbeePacketType packetType,

                                                      uint8_t *packetData,

                                                      uint8_t *size,

                                                      void *data);

PacketType is one of the packet types described below

packetData is a buffer containing the payload of the message with the first byte holding the information described in the table below

size is the length of the packet in bytes

data is auxiliary data which differs depending on the corresponding packet type

These callbacks are selected from the callbacks tab of the appbuilder under 'Non cluster related' callbacks. You can search for the term 'packet' and use the + sign to expand all categories for quicker access.

Packet Types

The table below lists all packet types used by the packet handoff feature and whether they are supported on the incoming and outgoing side. It also shows any corresponding auxiliary data and indicates what field first byte of the handed over payload comprises of.

Packet Type	Description	Packet starts with	Incoming (Aux Data)	Outgoing (Aux Data)
EMBER_ZIGBEE_PACKET_TYPE_ RAW_MAC	Raw 802.15.4 MAC message	IEEE 802.15.4	(macPayloadLength)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ BEACON	A beacon	IEEE 802.15.4 Beacon	(panId)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ MAC_COMMAND	802.15.4 MAC Command	IEEE 802.15.4 Command	(NULL)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ NWK_DATA_PRE_DECRYPTION	Zigbee Network layer data message prior to NWK decryption	Zigbee Network	(networkHeaderSize)	(n/a)
EMBER_ZIGBEE_PACKET_TYPE_ NWK_COMMAND_PRE_DECRYPTION	Zigbee Network layer command prior to NWK decryption	Zigbee Network	(networkHeaderSize)	(n/a)
EMBER_ZIGBEE_PACKET_TYPE_ NWK_DATA	Zigbee Network layer data message	Zigbee Network	(NULL)	(networkHeaderSize)
EMBER_ZIGBEE_PACKET_TYPE_ NWK_COMMAND	Zigbee Network layer command	Zigbee Network	(NULL)	(networkHeaderSize)
EMBER_ZIGBEE_PACKET_TYPE_ APS_DATA	APS data	Zigbee Application Support	(NULL)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ APS_COMMAND	APS command	Zigbee Application Support Command	(frameControl)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ ZDO	Zigbee Device Object command	Zigbee Device Profile	(emCurrentApsStruct)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ ZCL	Zigbee Cluster Library command	Zigbee Cluster Library	(NULL)	(NULL)
EMBER_ZIGBEE_PACKET_TYPE_ INTERPAN	Interpan message	Zigbee Cluster Library (with Interpan info)	(senderEui64)	(NULL)

Packet Actions

Both the incoming and the outgoing callbacks use an 'EmberPacketAction' as the return type. The following definitions are available for this. They are defined in ember-types.h.

Supported Packet Actions per Packet Type

Packet type	EMBER_ACCEPT_ PACKET	EMBER_ACCEP T_PACKET_OV ERRIDE_SECURITY	EMBER_ACCEP T_PACKET_SKI P_NWK_CRYPTO	EMBER_ DROP_PACKET	EMBER_MA NGLE_PACKET
RAW_MAC
BEACON
MAC_COMMAND
NWK_DATA_PRE_DECRYPTION
NWK_COMMAND_PRE_DECRYPTION
NWK_DATA			(outgoing only)
NWK_COMMAND			(outgoing only)
APS_DATA
APS_COMMAND
ZDO
ZCL
INTERPAN

Note: Any unknown or unsupported return value provided through the callbacks is treated as EMBER_ACCEPT_PACKET.

(x)NCP support

The packet handoff plugin as described above is only available in SoC mode. This is to avoid overloading the serial lines between the host and NCP with these intermediary packet types. 

When building an xNCP the following two callbacks are available on the NCP

EmberPacketAction emberPacketHandoffIncoming(EmberZigbeePacketType packetType,

                                             EmberMessageBuffer packetBuffer,

                                             uint8_t index,

                                             void *data);

EmberPacketAction emberPacketHandoffOutgoing(EmberZigbeePacketType packetType,

                                             EmberMessageBuffer packetBuffer,

                                             uint8_t index,

                                             void *data);

packetType is one of the packet types described below

packetBuffer is a message buffer containing the complete message as it is handled by the stack

index is a pointer to the first byte in the packet buffer which represents the start of the defined packet type

data is auxiliary data which differs depending on the corresponding packet type

These functions are also available on the SoC and feed into the packet handoff plugin which in turn exposes 

emberAfIncomingPacketFilterCallback()

and

emberAfOutgoingPacketFilterCallback()

as described above.

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 

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

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:

• Design and Assembly guidelines when using xGM parts based System in Package (SiP)
• Antenna tuning for BGM12x (coin-cell usage example)
• BGM12x SiP Module Layout Recommendations.
• GND plane shaping when using E variant of modules
• What is a STEP file and how to obtain a STEP file for Silicon Labs IOT products?

[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:

• How to insert a SAW filter / RF switch / FEM into the EFR32 Series 1 sub-GHz reference matching networks.
• Discrete matching solutions for EFR32 Series 1 sub-GHz designs
• Overview of EFR32 series 1 matching networks for 2.4Ghz frequency band
• EFR32 Series 1 sub-GHz single-ended operation
• Recommended external antenna matching network
• EFR32 2.4GHz discrete RF match
• EFR32 optimum load impedance at 2.4GHz

[2] RF

Application Notes:

• AN928.1: EFR32 Series 1 Layout Design Guide
• AN933.1: EFR32 Series 1 Minimal BOM

Knowledge Base Articles:

• Comparison of EFR32 series 1 pin connections for standard versus non-radio based applications
• RF Range Calculator
• Range improvement calculation for a given extra link budget
• RF range factors
• 2G4RF_ION pin connection on EFR32
• Maximum allowed power for ZigBee applications under ETSI EN 300 328
• EFR32 Minimal BOM filtering
• Purpose of SAW filters
• Z-Wave 700: SAW filter recommendations
• Recommended routing technique for more-layer RF designs

[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:

• PCB antenna with wider bandwidth
• Whip antenna parameters
• Whip antenna Length and Size
• Do loop antennas require a ground plane?
• Design tip for dipole antennas

[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:

• EFR32 VDD rail relations
• EFR32 Series 1 PA DC feed
• EFR32 Series 1 DC-DC to PAVDD
• How do I use the CTUNE token for EFR32?
• Powering External Circuits from EFR32 DC-DC
• Using a TCXO with an EFR32
• Enhanced filtering of EFR32 Series 1-based designs for XO reference spur suppression
• How to enable voltage scaling in EM2 mode for EFR32MG12 and later devices
• EFR32xG1 SW changes if 4.7uF DC-DC capacitor is used
• EFR32 Maximum External Pull-up / down Resistor Values

[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:

• How to maximize the isolation of coexistence antennas on the same PCB
• Board-level ESD protection of RF devices
• Tips for FCC certification on Silicon Labs' 2.4GHz 802.15.4-based solutions
• Hardware Design Review submission expectations for EFR32MGxx based designs
• KBA_BT_1301: How to find schematics and other documentation for radio boards?
• Layout design practices around the output of an on-chip DC-DC converter
• Are all EFR32 parts of the same package variant pin-compatible?
• Where can I find BSDL file for EFR32 Wireless Gecko devices?
• PCB number of layers vs Output power
• Custom design PCB number of layers
• Key Dimensions of the Main Board BRD4001A
• How do I determine the PCB and schematic version of kit boards?
• Data rate, deviation, modulation index for 2GFSK modulated signals
• Modulation choice
• Calculation of the occupied bandwidth for digital frequency modulation
• Calculation of the modulation index for digital frequency modulation
• EFR32xG devices inside BGM/MGM modules
• RF shield vs. RX immunity
• My EFR32 is not outputting the power I'm expecting for my zigbee (EmberZNet) application. How do I improve it?
• How to Manually Set-up the Arb Waveform Generator for functional test

Purpose: TIS/TRP testing is an optional test for 802.15.4 Zigbee compliance, but is a mandatory test for some ecosystems. This KBA introduces how to test and estimate TIS/TRP.

1.  TIS/TRP overview

Total Isotropic Sensitivity (TIS)

A measure of the average sensitivity of a receiver-antenna system, when averaged over the entire 3-dimensional sphere. The result will be strongly related to the antenna's radiation pattern. The TIS would be equal with the conducted sensitivity value if an ideal isotropic antenna was utilized, but when using a real antenna the TIS is weaker than the conducted sensitivity and depending on the antenna efficiency. 

Total Radiated Power (TRP)

A measure of how much power is radiated by an antenna when the antenna is connected to an actual radio transmitter. TRP is an active measurement, in that a powered transmitter is used to transmit through the antenna. The total received power is calculated over the entire 3-dimensional sphere, and the result is the Total Radiated Power. The result will be strongly related to the antenna's radiation pattern. The TRP would be equal with the conducted power (antenna input power) if an ideal isotropic antenna was utilized, but when using a real antenna the TRP is weaker than the conducted power and depending on the antenna efficiency. 

2.  Test Environment 

The test environment involves three main components as follows:

RF test equipment and Test PC with software: The test software is running on a Test PC controlling the test measuring instruments, e.g. Signal generator and Spectrum analyzer, and the command module.

Command module: This module receives the test commands from the Test PC and forwards these commands in a consumable format to the DUT. It reports ACK results received from the DUT to the Test PC.

DUT: The device under test placed within an anechoic RF chamber.

3.  Test channels

The minimum channels for TIS and TRP testing are shown in the Table below and only test device supported frequency bands (868MHz, 915MHz and/or 2.4GHz range) should be tested.

4. Test method and procedure

The TIS and TRP tests should follow the guidelines outlined in CTIA documents listed below. These tests are usually done and reported by a professional, certified test laboratory.

 CTIA: “Test Plan for Wireless Device Over-the-Air Performance"

 CTIA: "Test Plan for Mobile Station Over the Air Performance”

4.1  TIS Test method and procedure

The DUT is placed in a free-space holder on a rotation table within the anechoic RF chamber and the communication between the DUT and the command module is established via over-the-air inside the chamber. The command module converts the commands of Test PC to control the DUT to the required test channel. To determine the TIS the reference antenna in the RF chamber transmits at the DUT, and the TX power is lowered until the radiated sensitivity BER or PER limit reaches a given threshold. The DUT then rotates in increments of 30 degrees along the vertical axis. At each vertical position, the horizontal axis steps in increments of 30 degrees. The horizontal and vertical polarization are measured at each position. After all measurements are completed, the sensitivity is calculated at each measurement point and the TIS is automatically calculated. Repeat this procedure on all test channels.

The test procedure as follows:

• DUT shall receive TX packets from a Signal Generator's output.
• Signal Generator transmits a standard conforming signal and packet.
• Measure free space effective isotropic sensitivity (EIS) pattern. Adjust the TX downlink signal level until the PER=0.04% threshold is reached. The downlink step size shall be no more than 0.5 dB when the downlink power is near sensitivity.
• Calculate using EIS pattern. For a complete sphere measured with N Theta intervals and M Phi intervals, both with even angular spacing, the Total Isotropic Sensitivity is calculated as follows. Usually this calculation is done by the test LABS, which have an automated calculation tool for this purpose. 

​

• Repeat on all test channels.

4.2  TRP Test method and procedure

The DUT is placed in a free-space holder on a rotation table within the anechoic RF chamber and the communication between the DUT and the command module is established via over-the-air inside the chamber. The command module converts the commands of Test PC to control the DUT to the required test channel and output power level. To determine the TRP the reference antenna in the anechoic RF chamber receives signal from the DUT, and the incoming signal strength is measured by a Spectrum Analyzer via the reference antenna. The DUT is then rotated along the vertical axis in 15° increments. At each vertical position, the horizontal axis is stepped also in 15° increments. Measurements are taken for both horizontal and vertical polarization at each position. After all the measurements have been taken, the power is calculated at each measurement point and the TRP is automatically calculated. Repeat this procedure on all test channels.

The test procedure as follows：

• Spectrum Analyzer shall receive TX output signals from the DUT. The transmit power level of the DUT used for TRP testing shall be the same as what the actual products being used and shall comply with regional regulations. 
• Measure free space effective isotropic radiated power (EIRP) pattern.
• Calculate TRP using EIRP pattern, For a complete sphere measured with N Theta intervals and M Phi intervals, both with even angular spacing, the Total Radiated Power is calculated as follows. Usually this calculation is done by the test LABS, which have an automated calculation tool for this purpose. 

• Repeat on all test channels.

5.  A simple method to estimate TRP/TIS

DUT's TX/RX conducted performance should be measured and antenna efficiency is used to estimate the TRP/TIS. This method can only be used for estimation, since there might be errors between the calculated result and the actual radiated TIS/TRP, and the reasons can be the followings.

Firstly, the antenna is picking up noise from all the electronic equipment that make up the system under test. That means, the antenna picks up added noise which can deteriorate the radiated sensitivity (which may have not been observed during conducted receiver tests). Also, the antenna efficiency is always less than 0 dB (100%) due to the lossy material of the antenna (and possible non-perfect antenna match), so the TIS will always be worse (higher) then the receiver’s conducted sensitivity.

Secondly, TRP/TIS measures the radiated performance in an actual live system. As a result, it is a function of not just the radio/transmitter, but also the antenna, and the connection between these. Even though both the radio/transmitter/receiver impedance and antenna impedance are designed to be 50 Ω, in reality they can slightly deviate from 50 Ω thus a small part of the RF power is likely reflected at the connection (i.e. mismatch loss).

5.1  TIS estimation

The procedure as follows:

• Measure the conducted receiver sensitivity (0.04% PER) and antenna efficiency. The antenna efficiency can be measured using a near-field antenna scanner (e.g. the EMSCAN RFxpert) or measured and reported by a test lab.
• The TIS can be calculated by TIS [dBm] = Conducted Sensitivity [dBm] – Antenna Efficiency [dB]. This method does not check the sensitivity in radiated way and thus does not take into account any possible radiated sensitivity degradation due to possible spurs/noises/interference appearing in the RF band, if any. So, it is recommended to check the radiated sensitivity in a known antenna gain pattern direction as well if that is as expected based on the conducted sensitivity and antenna gain parameters.
• Another method for TIS estimation however checks the sensitivity in radiated way also as follows: TIS [dBm] = EISmin [dBm] + D [dBi] where EISmin is the minimum EIS (measured in the max gain direction), and D is the antenna directivity (D [dBi] = Gain [dBi] – Efficiency [dB]).
• For example, the DUT conducted sensitivity is -100dBm, antenna efficiency is 40%, The TIS = -100 - ( 10*LOG10*(40/100)) = -100 - (-4)= -96dBm

5.2  TRP estimation

The procedure as follows:

• Measure the conducted output power and antenna efficiency. The antenna efficiency can be measured using a near-field antenna scanner (e.g. the EMSCAN RFxpert) or measured and reported by a test lab.
• Calculate TRP using the conducted result and the known antenna gain parameters in the main radiation direction/lobe. The TRP can be calculated by TRP = ‘conducted output power [dBm] + antenna efficiency [dB]’, or TRP = ’EIRP (conducted output power + antenna gain) - antenna directivity', where efficiency [dB] = gain [dBi] – directivity [dBi].
• For example, the DUT conducted max output power is 20dBm, antenna efficiency is 40%, The TRP = 20 + (10*LOG10*(40/100)) =20 + (-4) = 16dBm

6.  Additional Details

Additional background and details can be found in the reference Zigbee Alliance specification document of "docs-19-01701-00-Zigbee RF Performance (TRP/TIS) Specification & Test Plan".

For the test code/FW description for TRP/TIS measurements please refer to the following KBA: How to build and use the StandardizedRfTesting sample in EmberZnet SDK?

Description

This article shows how to configure the Green Power On/Off Switch sample application to be a (more) energy-optimized project and then demonstrates the energy profiling with it on EFR32MG22. Stack version used: 6.7.6

Preparing the project

First, you have to configure the Green Power On/Off Switch sample application. This means you have to disable the onboard LEDs, Serial ports, the CLI, and reduce GPD BiDirectional Rx Window. 

1. Create a Green Power On/Off Switch sample application as a Silicon Labs Appbuilder Project

• When creating the project, make sure you select your EFR32xG22 board. 

2.  Configure the .isc file

• Open the Plugins tab and make the following changes:
  • In the GPD App Configuration plugin change the GPD BiDirectional Rx Window to 8-10 msec. It will reduce energy consumption during BiDirectional communication. It has no impact on sleep mode current draws.
  • Disable LED, GPD CLI, and the Command Interpreter plugins.
  • In the Serial plugin, make sure all the 3 Peripherals are disabled. Unfortunately, you cannot turn off all the I/O plugins, because the HAL library requires them. To disable their effect, you have to add some macros in step 5.
• In the CLI tab, disable Command line interface.

3. Generate the project 

4. Modify the hwconf file

Open the hwconf file of your project in Hardware Configurator. Switch to DefaultMode Peripherals view then disable Virtual COM Port. Since serial communication is disabled, there is no point in keeping the VCOMPort enabled and it would just increase the power consumption. After the modification, save the file. 

5. Modify the callbacks file

• Open gpd-switch-callbacks.c file and add the following #undef macros after this code section:

  #if defined(EMBER_AF_PLUGIN_SERIAL)
  #include EMBER_AF_API_SERIAL
  #endif
  
  #undef EMBER_AF_PLUGIN_EMBER_MINIMAL_PRINTF
  #undef EMBER_AF_PLUGIN_SERIAL

  With these lines added, we disabled the effects of the I/O plugins that were mentioned in step 2. 

• To prevent further compile errors, you have to add a type definition and implement the following function as a dummy function:

  typedef uint32_t Ecode_t;
  Ecode_t COM_ForceWriteData(COM_Port_t port, uint8_t *data, uint8_t length ) {}

  You can add these lines after the #undefs.

6. Modify hal-config.c file

For correct EM2 current, MG22 boards require the following macros to be added to the hal-config.c file:

#define HAL_EMU_ENABLE (1)
#define HAL_EMU_EM23_VSCALE HAL_EMU_EM23_VSCALE_LOWPOWER
#define _EMU_DCDCCTRL_MASK (1)

7. Compile and flash the program to your board

If you successfully programmed your board, you can start the energy profiling. You can measure the current draw in different Energy Modes and measure different commands' power consumption. The device first goes to Energy Mode 2 (EM2) then after the 10-sec timer expires it goes to EM4. This 10 second can be changed in the callback file. Waking up from EM4 is only possible with the toggle button (PB1).

Note: The MG22 board has an MX25 series SPI serial flash on it. If it is not configured properly, your current consumption can be greater with 7-8 μA than in the following pictures (both in EM2 and EM4). The chip can be put into Deep Power Down (DPD) mode, in which its current draw is around 100 nA.  To do it, SPI communication is required thus the serial ports are also required, which would increase the current draw. A solution is to first upload an application that has SPI interface enabled (in Hardware Configurator) and issues the chip to DPD as described here. It is also possible to physically remove the chip from the radio module.

Without the MX25 chip, EM2 current should be around 1.8 μA while EM4 current should be around 300 nA.

Commission with reduced BiDirectional Rx Window

Since we reduced the BiDirectional Rx Window, we cannot commission the device with a Z3LightGPCombo. The reason is that the window of receive time is too short for the proxy's debug prints. To solve this issue, you have to disable the CLI on your Z3LightGPCombo. You can put the sink into commissioning mode by pressing PB0.

Measuring power consumption with Simplicity Studio Energy Profiler

Simplicity Studio offers a very convenient, but not the most accurate method for measuring power consumption. This document helps you to get started with Simplicity Studio Energy Profiler.

Note: Energy Profiler's “scope” capabilities and measurement accuracy (1 μA) are limited by the 10 kHz maximum sampling rate of the AEM circuitry on the WSTK. In the picture below, you can see some command's current draw spike and EM2-EM4 currents.

Measuring power consumption with lab instruments

A more precise way to make the energy profile is to use a DC Power Analyzer. These devices usually provide the possibility of measuring with 4-wire sensing technique. 

A detailed description of the measurements with lab instruments can be found here in section 2-3.

Measurements with a digital multimeter

Profiling different commands' energy consumption

GP message frames may contain different payloads alongside with the command ID. You can read more about command payloads in the Zigbee Green Power Specification. These payload lengths affect the energy consumed by sending the command. 

With the project you made before, you can measure the power consumption of different commands. (For this, your device is not required to be commissioned.)

In gpd-switch-callbacks.c, find the sendToggle function. The Toggle command is a payloadless command, so there is only one byte in the command array (the command ID). You can add more bytes (payloads) to this array and observe how the energy consumption changes with PB1 presses. A noticeable change can be seen if you start increasing the payload length by i.e. 5 bytes. 

In the pictures below you can see the difference of the power consumption between a payloadless and 32 bytes length payload command:

Application "tokens" are bits of data stored in Non-Volatile Memory (NVM). They are created with a Token Key so that the information stored can be easily retrieved by the application layer without knowing the absolute memory address (note: more details about tokens can be found in AN1154: Using Tokens for Non-Volatile Data Storage and about NVM storage in either AN703: Using Simulated EEPROM or AN1135: Using Third Generation NonVolatile Memory (NVM3) Data Storage).

Simplicity Studio's AppBuilder currently (as of SV4.x.x) creates the token file and allocates token keys to these tokens every time an application is generated or regenerated. For Zigbee projects you can find the application tokens that will be stored in NVM in file <project_name>_tokens.h

However, AppBuilder has no knowledge of token keys that were used previously for the same the token data. If new tokens are created during the generation, for example we want to store additional cluster attributes to NVM, then the new token keys could conflict with the existing token keys.

This has limited impact during development but could be a problem when OTA updating deployed devices.

If the means to access the tokens that were used previously (in the previous version of an application) are not preserved, then the new application can produce indeterminate results when it is run. The new token key may have been used for a different token in the previous version of the firmware. So, the token that used to represent the binding of the application might now map to the space for the setting of the light color, etc... As some application settings are stored in NVM, this could result for example, in a light that was warm white now turning cool white after the OTA upgrade, or that was OFF to now be ON.

This is undesired and you want the light to come back online exactly as it was before the OTA upgrade without the need for a reset to factory defaults. In order to ensure this behavior, the layout of the token address space must be preserved across application upgrades.

Note that this relates to application tokens and not to stack tokens. The token keys for stack tokens are fixed/preserved so that after an OTA update the device can rejoin the network that it belongs to without user intervention. A factory reset would clear these tokens resulting in the device being removed from the network. The stack tokens can be found in file <SDK_install_directory>/stack/config/token-stack.h

The Silicon Labs team is working on a long-term solution for this but until one is available inside Simplicity Studio we’ve created a script that provides a workaround for the problem.

It does this by first reading the 'old' token header file and then reading the 'new' token header file. From these two files it 'writes' a 3rd token header file which preserves the token key values of the 'old' file while at the same time assigning unused token key values for the 'new' tokens. This ensures that any new tokens will be initialized to their default values and preserves the values of the previously defined tokens.

So, an application token for light temperature will continue to use the same token key after the OTA upgrade of the device. The light that was warm white prior to OTA upgrade will continue to be warm white after the OTA upgrade.

This script is written in Node.js and you need to make sure you have the node engine on your workstation. It can be downloaded from the official Node.js site.

The “Token Preserver” script can be found on Silicon Labs GitHub repository.

With the node engine installed you run: 'node token_preserver.js' in your shell and it will print out the usage information.

An example to demonstrate this uses two header files, 1-old.h (used with the original application) and 1-new.h (generated by the updated application) resulting in an updated 1-mod.h below.

We can see that in the original application the following token keys:

CREATOR_START_UP_ON_OFF_1, CREATOR_CURRENT_LEVEL_1, CREATOR_OPTIONS_1 and CREATOR_START_UP_COLOR_TEMPERATURE_MIREDS_1

didn’t exist. These have been created by app builder when generating the new project but need their token key values to be renumbered by the script. Note that “creator code” is the same as token key (see AN1154 section 3.2.1 for details).

Several of the other token keys in 1-new.h though did already exist, but with different token keys in 1-old.h. If the newly created token keys do not match those of the original application, then the data fetched by the application will represent something else.

For example; in the 1-new.h file the token key 0xB004 is used for the CREATOR_CURRENT_LEVEL_1 token whereas in the devices memory, which uses token keys specified in 1-old.h, that key is used with token CREATOR_COLOR_CONTROL_CURRENT_X_1. The script changes the token key value for the updated application to match the original.

The final step is to replace the 1-new.h file that was generated when creating the new project with the 1-mod.h file that has been created using the token-preserver script. Then rebuild the project.

• AN1154: Using Tokens for Non-Volatile Data Storage
• AN703: Using Simulated EEPROM
• AN1135: Using Third Generation NonVolatile Memory (NVM3) Data Storage
• Token Preserver
• Silicon Labs GitHub repository
• Node.js

    当客户或FAE想要在Salesforce中创建一个硬件设计评审服务的案例时，他或她须检查以下能对无线SOC和模块进行彻底有效评审的预期事项，这是非常重要的。

• 提供产品用例的简短描述。

• 提交原理图评审的检查清单

  • 原理图应以可搜索的PDF格式提供，因为这将允许评审人在多张页面的原理图中搜索指定的网络或器件。

  • 最好提供整个设计原理图，但是，如果因保密要求而无法提供整个原理图，那就在案例说明中提供所用电源、主机MCU型号和其他无线器件型号（如有）的详细信息，以便彻底评审。例如，如果设计中有WiFi部分，而在提供的原理图中看不到，那么我们提供的评审反馈就不那么完整，因为在单个PCB上临近位置的多个无线电需要额外的软件和硬件更改来改善无线电之间的共存。

  • 在原理图中未提及的情况下，提供连接到EFR32的所有元器件的型号，因为元器件特性可能因尺寸不同而不同，就可能影响预期的性能，例如，由于匹配网络的失调而影响的射频性能。另外，请提供HFXO和LFXO（如有）晶体的规格书，因为晶体可能有多种变量，如果没有提供完整的型号，找到正确的规格书将会令人困惑。

  • 除了规格书的建议外，还应参考以下文件，并尽可能遵循原理图设计指导，以达到最佳性能。

    • 

    •  芯科实验室的相关器件参考板的原理图。选择参考设计中的满足规格书要求的元器件值。

• 提交PCB布局布线评审的检查清单

  • PCB布局布线应以Gerber文件格式提供所有层，包括焊接掩模、锡膏和钻孔文件。一般来说，Gerber文件是提供给PCB制造商的，因此重要的是评审最终设计文件，而不是CAD文件本身，以便检查可能导致制造或性能问题的任何异常。

  • 除了规格书建议外，还应参考以下文件，并尽可能遵循PCB布局布线指导，以实现最佳性能，尤其是射频性能。

    • AN928.1 for EFR32xG1x

    • AN928.2 for EFR32xG2x

    • 芯科实验室的相关器件参考板的PCB布局布线图

• 如果以前无线硬件团队在另外的案例入口中评审过相关的设计，则以以前的案例（案例中评审了相同的设计）为父案例来创建新的案例。为了便于追溯，将相似的案例关联在一起是很重要的。