FCC testing is an important milestone in wireless product deployment. The Federal Communications Commission (FCC) is responsible for regulating communications equipment in the United States, including acceptable use of frequencies in the licensed and unlicensed bands. All wireless products, such as those using IEEE 802.15.4 or ZigBee or Thread, must undergo FCC testing prior to being sold in the North American marketplace.

If your are considering FCC certification on your EFR32-based or EM3xx-based device, the FCC testing report (from Curtis-Straus), a PDF linked at the bottom of this article, for our legacy EM260 radio communications module (RCM) may be useful to you as a reference. Note that while Silicon Labs' RCMs (from the original Ember EM2xx development kits) have completed the necessary FCC test conditions for certification, the RCM itself is not an end product with an FCC ID (since it is intended for development), so it can only be used in development & demonstration context. Even if you build a replica of our RCM design, you will still need to undergo FCC end-product certification testing for your hardware.  The same applies to EFR32-based radio cards found in the Mighty Gecko Mesh Networking Kit.  (RF modules found in EM35x Developer Kits were exceptions to this rule as they were commercially available modules produced by third parties such as Telegesis or CEL.)

Below are some notes and tips relevant to the testing:

Duty Cycle Correction Factor:  If you encounter difficulties passing the Radiated 2nd and 3rd Harmonic Level testing (measurement of signal energy at frequency*2 and frequency*3) with a design based on Silicon Labs' hardware reference designs, it may be necessary to use a Duty Cycle correction factor that takes in to account the worst case timing (amount of time in TX Mode in any 100ms window). Note that you may not need to use the Duty Cycling correction factor if the output power from the 2.4GHz radio is reduced to below the default 3dBm (and no Boost mode or PA is enabled), but reducing power will, of course, have an adverse effect on your achieved communication range between devices. In case your test house needs the duty cycle calculations (which are consistent across any device employing an 802.15.4 MAC layer implementation), they are attached here as an Excel 2003 spreadsheet.

The attached FCC test report for the EM260 RCM uses a -11.34 dB duty cycle correction factor, which is based on a 27% TX duty cycle. This duty cycle measurement was based on an observed, worst-case measurement for the specific application being tested. If you are unable to provide test data to your FCC test house illustrating the real-world worst-case TX duty cycle (such as in a failed link scenario with all expected retry mechanisms activated) for your target application firmware, you can instead use a correction factor based on the computed worst-case value for an 802.15.4-compliant ZigBee stack, which is 66%, as reflected in the attached Duty Cycle TX spreadsheet. Note that the 66% measurement assumes worst-case values achieved in several randomization functions, so your observed, real-world application performance will almost certainly be less than this number. Regardless of how you arrive at your TX duty cycle percentage (P), the correction/relaxation factor (F) applied to your harmonics emissions will be based on the following formula: F = 20 * log(P/100). For example, a 66% TX duty cycle yields a duty cycle correction factor of -3.6 dB = 20 * log(0.66).

PA Compression: If using an external PA (power amplifier), you may notice some noise or other spurious emissions leading to higher than expected EVM in the transmitter waveform. If you see this, may be an indication that the PA is in compression, so you'll want to back the TX power down a bit (in software), to just before the amp hits compression, so that you still get the maximum output from the amplifier without the added distortion. (This will require some trial and error in order to determine the optimal point where compression is eliminated with minimal sacrifice to output power.) Proper radio circuit performance should always be verified before (and after) applying the PA to the circuit, as using the PA to compensate for poor transmission power can cause adverse side effects.

Board Troubleshooting: Other spikes in the output, excessive harmonics or abnormally low output power generally indicate manufacturing or design issues with your hardware, so you should check to ensure that the design is laid out according to Ember’s reference designs and design guidelines (see “PCB Design with…” documents among references list at the end of this article) and that the manufacturing quality is satisfactory. This includes the following areas:

•proper grounding and capacitive decoupling of the chip (coupling of noise can produce harmonics), which includes following Silicon Labs' reference design to prevent noise from coupling into the RF by properly routing traces concerning placement of vias, then decoupling capacitors, then IC pads. (In general RF component pads should be placed in line with the traces and not branched off the signal path. Crystal circuits should be kept as short as possible, and crystal shunt capacitors should be tied to the same ground via. More details are contained in Silicon Labs' reference designs.)

•proper seating of the Silicon Labs IC on the solder and vias underneath the chip: Design wise, too many vias can reduce the temperature at the ground pad of the chip during reflow, causing it to have a cold solder joint; large paste stencil openings can cause too much solder to be placed under the chip, causing some outer pins not to be soldered properly; insufficiently large solder openings in the paste stencil for the chip can cause a poor ground connection to the chip; manufacturing reflow temperature profile could be incorrect, causing the solder under the chip not to flow properly, thereby resulting in a cold solder joint on the ground pad. Be sure to follow Silicon Labs’ footprint recommendations to avoid manufacturing defects. (Traces and vias should not be placed under the corners of the Silicon Labs IC.)

•proper antenna matching (to 50 ohm impedance with respect to nearest ground plane), including any inductor tuning that may be necessary from changes to board housing (such as adding an RF shield)

•adequate transmitter configuration via manufacturing tokens and GPIO:

For EM3xx-based devices, the MFG_PHY_CONFIG token (a non-volatile value set in the Customer Information Block area of Silicon Labs RF SoCs/NCPs) is the preferred means of configuring the default transmitter mode of the Ember ZigBee chips, including use of the alternate RF port (RF_TX_ALT_P/N) or standard, bidirectional port (RF_P/N) for an external PA, adjustment of ramp-up time at the PA and use of Boost Mode for additional receiver gain.  For EM35x devices using EmberZNet Pro 4.7.4 and later, the MFG_CCA_THRESHOLD token should be set when using an external LNA so that the radio's CSMA scheme works properly with the increased noise floor.  Additionally, if the external PA/LNA or RF front-end module (FEM) requires external control logic, these signals must be configured appropriately in the software's GPIO configuration (usually via the Board Header file for SoC designs or the following EZSP commands for host applications with an EZSP NCP: ezspSetGpioCurrentConfiguration, ezspSetGpioPowerUpDownConfiguration, ezspSetGpioRadioPowerMask).  See AN710 for further details.

For EFR32-based devices, the MFG_CTUNE token (a non-volatile value set in the UserData area of the IC during the PCB manufacturing/test process) can be used to make fine adjustments to the crystal frequency to achieve the ideal center frequency in the radio, and halInternalSetCtune() (defined in platform/base/hal/micro/cortexm3/efm32/micro-common.h) can be used to experiment with different values at run-time during manufacturing test or design validation to understand what is the ideal for the CTUNE token on that particular design.  Additionally, PHY transmitter configuration can be made at compile-time using the RADIO_PA_2P4_INIT structure defined in the board header file (usually called {ProjectName}_board.h).  An example init structure for the 2.4GHz radio is shown below for reference:

#define RADIO_PA_2P4_INIT                                                     \
  {                                                                           \
    PA_SEL_2P4_HP,    /* Power Amplifier mode */                              \
    PA_VOLTMODE_DCDC, /* Power Amplifier vPA Voltage mode */                  \
    100,              /* Desired output power in dBm * 10 */                  \
    0,                /* Output power offset in dBm * 10 */                   \
    10,               /* Desired ramp time in us */                           \
  }

See AN961 for more details around manufacturing-time configuration of 2.4GHz-based EFR32-based devices.

Band Edge Concerns: The top end of the 802.15.4 channel band (Channel 26 and occasionally Channels 24 an 25 at very high output powers) usually pushes up against the limits of the band, encroaching into the reserved area in the adjacent (higher) frequencies. Therefore, it's often necessary to artificially limit (with software) output power on these upper channels (as much as -9 or -10 dBm) in order to pass FCC TX testing.

Shielding: Depending on the amount of harmonics output and packaging design, you may want to consider a shield around your RF circuit. While this is not required to pass FCC certification unless you want to achieve certification as a commercial module for re-use as a component, some customers find it helpful in suppressing 2nd harmonics on the circuit.

Required tests: Required FCC testing for 2.4GHz DSSS devices such as ZigBee or Thread solutions should involve tests 15.209 and 15.247 from FCC CFR 47 Part 15. These are RX testing and TX testing, respectively. Other tests shouldn't be required, provided you're staying within the usual limits of 20dBm (100mW) output power.

Performing the tests: As far as performing the necessary tests, during the RF evaluation or design validation phase, the radio test modes for the EM35x chips can be accessed using the special NodeTest firmware, provided pre-built in the EmberZNet and Silicon Labs Thread software releases.  While similar NodeTest firmware is also provided in pre-built form for EFR32MG-based devices, this is built to the hardware configuration (GPIO pinout and power supply setup) of the specific radio boards released for use with the Mighty Gecko 2.4GHz Mesh Networking Kit.  Customers seeking a command line-driven test program for custom-built EFR32-based devices should consider installing the Flex SDK (a Silicon Labs wireless solution for design of proprietary RF products) and building the RAIL Test application contained in that SDK's application framework.  This sample application uses low-level RF test APIs from the Radio Abstraction Interface Layer (RAIL) library contained in the Flex SDK to execute many of the same RF test modes performed by NodeTest and can be built with a customer-supplied board configuration.

As the hardware design moves from initial validation to large-scale production test, test functionality similar to NodeTest or RAIL Test should be incorporated into the application by the firmware designer via the Manufacturing Test Library ('mfglib') command set in EZSP (the serial protocol that normally runs on EmberZNet Network CoProcessor [NCP] platforms, described in document UG100) or the “mfglib” library APIs found in the EmberZNet or Silicon Labs Thread stacks as the optional Manufacturing Library plugin through their respective application frameworks.  See Manufacturing Library CLI plugin (app/framework/plugin-soc/manufacturing-library-cli) in the ZigBee Application Framework for an example of application code that utilizes this mfglib command set / library to perform low-level functional testing.

Additional details about low-level functional testing can be found in Application Notes AN700 (Manufacturing Test Guidelines) and AN718 (Manufacturing Testing Overview).  See additional recommended hardware design, manufacturing, and testing references below.

References:
•AN0002 - Hardware Design Considerations for EFM32/EZR32/EFR32

•AN0016 - Oscillator Design Considerations

•AN0948 - Power Configurations and DC-DC

•AN698 - PCB Design with an EM35x
•AN700 - Manufacturing Test Guidelines
•AN710 - Bringing Up Custom Devices for the EM35x

•AN718 - Manufacturing Test Overview

•AN928 - EFR32 Layout Design Guide

•AN930 - EFR32 2.4 GHz Matching Guide

•AN958 - Debugging and Programming Interfaces for Custom Designs

•AN961 - Bringing Up Custom Devices for the Mighty Gecko and Flex Gecko (EFR32)

•Silicon Labs Reference Designs for ZigBee/Thread

Attachments (see further down for download links):
•Duty_Cycle_for_TX_calc_66pct.xls
•EH0533-2_EM260_RCM_Report.pdf