This article contains some frequently asked questions and answers about Connected Home over IP - CHIP
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:
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
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.
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.
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.
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.
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. 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:
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.
EmberPacketAction
Description
EMBER_ACCEPT_PACKET
The stack will continue processing the packet
EMBER_ACCEPT_PACKET_
OVERRIDE_SECURITY
Treat an incoming packet as if it was encrypted irrespective whether it is encrypted. On an outgoing packet clear the security bit in the NWK header.
EMBER_ACCEPT_PACKET_
SKIP_NWK_CRYPTO
An outgoing packet will not be NWK encrypted irrespective of its security settings. No functionality on an incoming packet
EMBER_DROP_PACKET
The packet will be dropped. The stack will not process it any further.
EMBER_MANGLE_PACKET
The contents of the packet have been changed in the packet handoff callback. The stack will continue to use the mangled packet
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
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.
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.
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:-
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.
Channel
Frequency [MHz]
0
868
1
906
4
912
7
918
10
924
11
2405
15
2425
20
2450
25
2475
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".
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 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:
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.
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.
Zigbee & Thread Knowledge Base
Connected Home over IP - CHIP FAQ
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
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.
OpenThread FAQ
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.
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.
Packet Handoff plugin how-to guide
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:
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
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
BEACON
(panId)
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
MAC_COMMAND
(NULL)
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
NWK_DATA_PRE_DECRYPTION
(n/a)
EMBER_ZIGBEE_PACKET_TYPE_
NWK_COMMAND_PRE_DECRYPTION
(networkHeaderSize)
(n/a)
EMBER_ZIGBEE_PACKET_TYPE_
NWK_DATA
(NULL)
(networkHeaderSize)
EMBER_ZIGBEE_PACKET_TYPE_
NWK_COMMAND
(NULL)
(networkHeaderSize)
EMBER_ZIGBEE_PACKET_TYPE_
APS_DATA
(NULL)
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
APS_COMMAND
(frameControl)
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
ZDO
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
ZCL
(NULL)
(NULL)
EMBER_ZIGBEE_PACKET_TYPE_
INTERPAN
(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.
EmberPacketAction
Description
EMBER_ACCEPT_PACKET
The stack will continue processing the packet
EMBER_ACCEPT_PACKET_
OVERRIDE_SECURITY
EMBER_ACCEPT_PACKET_
SKIP_NWK_CRYPTO
EMBER_DROP_PACKET
EMBER_MANGLE_PACKET
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
NWK_COMMAND
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
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
and
as described above.
What are the valid values for txPower in EFR32 devices?
The EFR32 families of chips each come equipped with multiple Power Amplifiers (PAs):
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:
*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
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:
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
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:
Knowledge Base Articles:
[B] EFR32 Series 1 Wireless SOCs:
[1] Matching Networks
Application Notes:
Knowledge Base Articles:
[2] RF
Application Notes:
Knowledge Base Articles:
[3] Antenna
Application Notes:
Knowledge Base Articles:
[4] MCU, Power Supply and Peripherals
Application Notes:
Knowledge Base Articles:
[6] Antenna Diversity
Knowledge Base Articles:
[7] General
Application Notes:
Knowledge Base Articles:
How to test and estimate TIS/TRP
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:
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:
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:
5.2 TRP estimation
The procedure as follows:
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?
Green Power Device Energy profiling on MG22
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
2. Configure the .isc file
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:
With these lines added, we disabled the effects of the I/O plugins that were mentioned in step 2.
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:
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:
How do I maintain application tokens when OTA updating devices?
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:
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.
提交基于EFR32MGxx硬件设计评审的预期事项
当客户或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布局布线图
如果以前无线硬件团队在另外的案例入口中评审过相关的设计,则以以前的案例(案例中评审了相同的设计)为父案例来创建新的案例。为了便于追溯,将相似的案例关联在一起是很重要的。