How do you switch antenna paths on EFR32MG21 and MGM210x in EmberZNet stack, and what are the defaults?
The value of antennaConfig.defaultPath in halInitAntenna() determines which antenna is in use.
At the time of publication of this article (EmberZNet 6.7.5), the RF2G4_IO2 pin is selected by default on both EFR32MG21 and MGM210x.
In EFR32MG21, the 2.4 GHz antenna interface consists of two single-ended pins, RF2G4_IO1 and RF2G4_IO2. See Figure 1.
EFR32MG21 chip pinout.
The MGM210P module has a built-in antenna on non-exposed pin RF2G4_IO1 and an external antenna attached to RF2G4_IO2 pin. See Figure 2.
MGM210P module pinout.
The MGM210L includes a built-in PCB trace antenna and does not support the use of an external, alternative antenna.
The following Figure 3. shows the lack of the RF pin.
MGM210L module pinout.
After the antennas and default paths are clarified, take a look at the application where this setting is applied. The stack first initializes the antenna GPIOs prior to any other radio settings being applied.
This is done by the
EmberStatus halInitAntenna(void) function through the Antenna Stub plugin.
It can be found in "...\v2.7\platform\base\hal\plugin\antenna-stub\antenna-stub.c ". See Figure 4.
Code snippet from antenna-stub.c .
The antennaConfig.defaultPath can be
The following table maps the above values with the corresponding pin configurations. See Table 1.
BSP_ANTDIV_SEL_LOC macro is defined to 1 in antenna.h, which means that the default path is the external U.FL for MGM210P and built-in PCB trace antenna for MGM210L.
When the customer or the FAE wants to create a support case in Salesforce for a hardware design review, it is important that he or she has reviewed the following expectations for thorough and efficient reviews of the Wireless SoCs and modules.
|Hardware Design Considerations||AN0002.1||AN0002.2|
|Oscillator design considerations||AN0016.1||AN0016.2|
|EFR32 2.4 GHz Matching Guide||AN930||AN930.2|
|EFR32 Sub-GHz Matching Guide||AN923||-|
|EFR32 Minimal BOM||AN933.1||AN933.2|
|Power Configurations and DC-DC||AN0948||AN0948.2|
|Debugging and Programming Interfaces for Custom Designs||AN958|
The StandardizedRfTesting sample application demonstrates the RF testing through TIS (Total Isotropic Sensitivity) / TRP (Total Radiated Power) interfaces. This sample is initial released in the 6.7.x EmberZnet SDK and can be used for customer's Zigbee product to pass the TIS / TRP RF testing. This article introduces how to build the StandardizedRfTesting sample and demonstrates how it works on Silabs BRD4162 radio boards.
Regarding the test procedure of the TIS / TRP is out of the scope of this KBA, please refer to the Zigbee Alliance specification "docs-19-01701-00-Zigbee RF Performance (TRP/TIS) Specification & Test Plan" for more information.
You will need
2 WSTK main board (BRD4001A)
2 radio boards, the brd4162 radio board is used in this exercise
Click File > New > Project This will launch the New Project Wizard.
Select Silicon Labs AppBuilder Project and press Next >
Locate the ZCL Application Framework V2 and select it, click Next >
Select EmberZNet 188.8.131.52 GA SOC 184.108.40.206 and click Next >
Select StandardizedRfTesting and click Next >
The Project Configuration page will come up, give your project a name. Leave the location as default. Click Next >
Finally, you will arrive at the Project Setup screen. Here we will select the parts and compiler we are using for this project. They are as follows:
Select Board: EFR32MG12 2.4 Ghz 10dBm Radio Board (BRD4162A Rev A00) and the part number will be selected automatically
Compiler: You can use gcc or IAR ARM to compile this project, for this exercise we use gcc: GNU Arm v7.2.1
Click the Finish button and wait for your project to be generated.
Click the Generate button to generate all of the files for your application.
Once generated, you will see a Generation validation dialog box. Make sure that you don't overwrite callbacks.c file as shown in this image. Click OK.
A Generation successful message should appear next. Click OK.
Click on your StandardizedRfTesting project and build using the hammer icon in the toolbar. Once built successfully, you will see the .s37 binary file in the project.
One verification test is to flash two WSTK radio boards with the StandardizedRfTesting firmware example as shown above in figure 1. One radio board works as DUT and another one works as Command Module. We can use the Command Module to attempt to communicate over the air with the DUT. This will verify that the DUT will be able to communicate with the test controller via OTA commands. The suggested process for this is:
Flash one WSTK radio board (DUT) with StandardizedRfTesting firmware and appropriate bootloader.
Flash another WSTK radio board (Command Module) with StandardizedRfTesting firmware and appropriate bootloader.
Power on the two radio boards. Connect the Command Module to laptop with USB cable.
Open the console of the Command Module: StandardizedRfTesting> cust find
If Command Module is successfully communicating with the DUT over the air, you will see this on the Command Module console: FIND ACK
If Command Module is no over the air communication, you will see the following on the Command Module console: NO PING ACK
Here is an example to show the CLI commands used during the TIS testing:
//The commands used in the TIS test case command flow: cust find cust rping cust rhardwareversion cust rsoftwareversion cust rsetchannel 0x00 0x00 0x10 0x00 // Set channel 12 for DUT cust lsetchannel 0x00 0x00 0x10 0x00 // Set channel 12 for Command Module cust lgetchannel cust lsetpower 0x0A // Set tx power to 10dBm for Command Module cust lgetpower cust rstart cust rend // Reset report count on DUT cust rstart cust silabs tx 100 // Send 100 packets to DUT, wait until the complete log cust rend // Get the report count on DUT
The prefix “r” and “l” of the command mean the command impacts on remote device (DUT) or local device (Command Module) respectively. For example:
“cust rsetpower 0x14”, which means set the tx power for remote device.
“cust lsetpower 0x14”, which means set the tx power for local device.
Regarding the four parameters of the rsetchannel/lsetchannel commands, which is the 32 bits channel mask (0xFFFFFFFF) split into 4 bytes. The bit0 is on behalf of channel 0, bit1 is on behalf of channel 1, bit2 is on behalf of channel 2, etc. So the 0x00001000 means channel 12. Here is some more example:
// channel 12 cust rsetchannel 0x00 0x00 0x10 0x00 // channel 15 cust rsetchannel 0x00 0x00 0x80 0x00 // channel 20 cust rsetchannel 0x00 0x10 0x00 0x00
The test result will be reported to Command Module from DUT after typing the command cust rend: StandardizedRfTesting> cust rend
[total]0x00001388 [protocol]0x00001388 [totalLqi]0x00078D98 [totalRssiMgnitude]0x0005B8D8
“total” is the total number of packets received in hex (here 0x1388 = 5000d). “totalRssiMgnitude” is the total RSSI in hex (here 0x5B8D8 = 375000). Avg RSSI can be found by dividing totalRssiMgnitude by total (0x5B8D8/0x1388 = 375000/5000 = -75.00 dBm). totalLqi is also available here, but the RSSI is more useful since it is what is used by the upper level tester to calculate the relative RX antenna pattern.
Note: The RF testing should be operated in shield room.
This KBA introduces how to build the StandardizedRfTesting sample step by step and demonstrates how to use the StandardizedRfTesting firmware for pre-test before sending your product to the test house. More info about the other related CLI commands you can refer to the source code in StandardizedRfTesting_callbacks.c file.