Working with RF front-end modules

An RF front-end module (FEM) is a device that amplifies the RF signal, to increase the range distance, the strength, and the robustness of a link connection. A more robust link reduces packet loss, causing fewer retransmissions and increasing the probability of successfully receiving the first packet, resulting in a lower link latency.

FEMs provide a power amplifier (PA) that increases the TX power and a low-noise amplifier (LNA) that increases the RX sensitivity. Some FEMs, like the nRF21540, also provide a power down (PDN) control that powers down the FEM internal circuits, to reduce energy consumption.

For testing purposes, a FEM is usually integrated in either a development kit or a shield that you can connect to a development kit.

This guide describes how to add support for 2 different front-end module (FEM) implementations to your application in nRF Connect SDK.

Software support 

To use radio protocols and a FEM with your application, enable Front-end module feature in the Multiprotocol Service Layer (MPSL) library.

The following test samples support FEM control:

You can also use your own FEM driver when required.

Using MPSL 

The MPSL library provides the following GPIO interface implementations:

GPIO mode - For the nRF21540 GPIO implementation that uses a 3-pin interface with the nRF21540.
Adding support for Skyworks front-end module - For the Simple GPIO implementation that uses a 2-pin interface with the SKY66112-11 device.

To use these implementations, your application must use a protocol driver that enables the FEM feature.

The library provides multiprotocol support, but you can also use it in applications that require only one protocol. To avoid conflicts, check the protocol documentation to see if the protocol uses the FEM support provided by MPSL.

Note

Currently, the following protocols use the FEM support provided by MPSL:

Enabling FEM and MPSL 

Before you add the devicetree node in your application, complete the following steps:

Add support for the MPSL library in your application. The MPSL library provides API to configure FEM. See Integration notes in the nrfxlib documentation for details.
Enable support for MPSL implementation in nRF Connect SDK by setting the CONFIG_MPSL Kconfig option to y.
Enable support for the FEM subsystem in nRF Connect SDK by setting the CONFIG_MPSL_FEM Kconfig option to y.
Choose the used FEM implementation by selecting the appropriate Kconfig option.

The following FEM implementations are supported:

The nRF21540 GPIO implementation, see GPIO mode. To use it, set the CONFIG_MPSL_FEM_NRF21540_GPIO Kconfig option to y.
The nRF21540 GPIO SPI implementation, see SPI/GPIO mode. To use it, set the CONFIG_MPSL_FEM_NRF21540_GPIO_SPI Kconfig option to y.
The nRF21540 2-pin simple GPIO implementation. To use it, set the CONFIG_MPSL_FEM_SIMPLE_GPIO Kconfig option to y.

Setting the FEM output power 

The tx_gain_db property in devicetree provides the FEM gain value to use with the simple GPIO FEM implementation. The property must represent the real gain of the FEM. This implementation does not support controlling the gain value during runtime.

nRF21540 implementations have the gain set to 10 by default. You can set a different gain value to use through the CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB option, but it has to match the value of one of the POUTA (CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA ) or POUTB (CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB) gains.

Caution

CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA and CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB are by default set to 20 and 10 and these are factory-precalibrated gain values. Do not change these values, unless POUTA and POUTB were calibrated to different values on specific request.

To enable runtime control of the gain, set the CONFIG_MPSL_FEM_NRF21540_RUNTIME_PA_GAIN_CONTROL to y. This option makes the gain of the FEM to be adjusted dynamically during runtime, depending on the power requested by the protocol driver for each transmission. For the nRF21540 GPIO implementation, you must enable the MODE pin in devicetree. For the nRF21540 GPIO SPI implementation, no additional configuration is needed as the gain setting is transmitted over the SPI bus to the nRF21540.

You can use only the Front-end module feature API if your application does not require other MPSL features. This might be useful when you want to run simple radio protocols that are not intended to be used concurrently with other protocols. Enable the following Kconfig options:

Using FEM power models 

When a protocol driver requests a given transmission power to be output, MPSL splits the power into the following components: the SoC Power and the FEM gain. This gain is considered constant and accurate even if external conditions, such as temperature, might affect the effective gain achieved by the Front-End Module.

To perform the split differently (for example, to compensate for external conditions), you can use a FEM power model, either using one of the built-in ones or providing your own custom model.

To use FEM power models, set the CONFIG_MPSL_FEM_POWER_MODEL Kconfig option to y and either select one of the built-in models or provide a custom model, as described in the following chapters.

Using nRF21540 GPIO SPI built-in power model 

Note

This is an experimental feature.

To use this model, set CONFIG_MPSL_FEM_POWER_MODEL and CONFIG_MPSL_FEM_POWER_MODEL_NRF21540_USE_BUILTIN to y.

This feature uses a model to compensate the FEM gain for the following external conditions:

Temperature
FEM supply voltage
Carrier frequency
FEM input power.

The model assumes that the FEM supply voltage is constant. To provide the value of this voltage to the MPSL subsystem, use the CONFIG_MPSL_FEM_POWER_VOLTAGE option.

Adding custom power models 

If the way MPSL splits the TX power into components does not meet your requirements, or if you wish to implement a custom compensation model, you can provide one as follows:

Set CONFIG_MPSL_FEM_POWER_MODEL to y
Provide an implementation of the mpsl_fem_power_model_to_use_get() function. This function should return a pointer to a variable of the type mpsl_fem_power_model_t which contains pointers to the model’s callbacks.
Mandatorily implement the model’s fetch callback (details explained below).
Optionally implement the model’s init callback (details explained below). If no init callback is provided, pass NULL as the pointer to the callback.
You can also optionally extend the MPSL_FEM_POWER_MODEL_CHOICE Kconfig choice with an option to select your custom model, for example, if you want to test multiple custom models.

The init callback is called by MPSL once, after FEM configuration finishes. Calibration data (acquired from FEM internal registers, Kconfig options, and devicetree files) is passed to this function using a parameter of the mpsl_fem_calibration_data_t type. The meaning of the calibration data stored in this parameter is implementation-specific. For details, see the mpsl_fem_calibration_data_t type documentation.

The fetch callback is used to split the power between the SoC output power and the FEM gain. It is called every time this split needs to be recalculated. For 802.15.4, this happens before every transmission. For Bluetooth® Low Energy, this happens every time the channel changes.

Note

This function is called in a time-critical path. Please refer to the documentation of mpsl_fem_power_model_t on timing constraints. Any complex calculations have to be done outside this function (for example, using a look up table). Failing to meet the timing requirements will lead to an undefined behavior of the protocol stacks.

The fetch callback must fill out all the fields of the the p_output output parameter. For more details, see the mpsl_fem_power_model_output_t type documentation.

Note

The soc_power field value must be one of the output power values supported by the given nRF SoC, otherwise the behavior is undefined. The user can meet this requirement by converting the requested SoC power using the mpsl_tx_power_radio_supported_power_adjust function.

Direct support 

If your application cannot use MPSL or if the FEM driver in MPSL does not support all features you need, you can implement your own driver for the nRF21540. The following samples have direct FEM support:

The implementations supported by the samples are the following:

SPI/GPIO mode - For the nRF21540 SPI/GPIO implementation that uses nRF21540.
Adding support for Skyworks front-end module - For the Simple GPIO implementation that uses the Skyworks devices.

Note

The nRF5340 DK network core peripherals, like UART and SPI, share an ID and a base address. To configure the nRF21540 front-end module gain, write the gain value over the SPI. In samples, UART is used as a control interface or shell transport. To send the gain value, UART is temporary disabled and restarted after the SPI transfer.

See the Bluetooth: Direct Test Mode samples for an example implementation.

Hardware description 

The nRF Connect SDK provides a wrapper that configures FEM based on devicetree (DTS) and Kconfig information. To enable FEM support, you must add an nrf_radio_fem node in the devicetree file. The node can also be provided by the devicetree file of the target development kit or by an overlay file. See Devicetree for more information about the DTS data structure, and Devicetree versus Kconfig for information about differences between DTS and Kconfig.

Adding support for nRF21540 

The nRF21540 device is a range extender that you can use with nRF52 and nRF53 Series devices. For more information about nRF21540, see the nRF21540 documentation.

GPIO mode 

The nRF21540 GPIO mode implementation of FEM is compatible with this device and implements the 3-pin PA/LNA interface.

Note

In the naming convention used in the API of the MPSL library, the functionalities designated as PA and LNA apply to the tx-en-gpios and rx-en-gpios pins listed below, respectively.

To use nRF21540 in GPIO mode, complete the following steps:

Add the following node in the devicetree file:

/ {
      nrf_radio_fem: name_of_fem_node {
         compatible  = "nordic,nrf21540-fem";
         tx-en-gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
         rx-en-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
         pdn-gpios   = <&gpio0 15 GPIO_ACTIVE_HIGH>;
   };
};

Optionally replace the node name name_of_fem_node.
Replace the pin numbers provided for each of the required properties:
- tx-en-gpios - GPIO characteristic of the device that controls the TX_EN signal of nRF21540.
- rx-en-gpios - GPIO characteristic of the device that controls the RX_EN signal of nRF21540.
- pdn-gpios - GPIO characteristic of the device that controls the PDN signal of nRF21540.
These properties correspond to TX_EN, RX_EN, and PDN pins of nRF21540 that are supported by software FEM.

Type phandle-array is used here, which is common in Zephyr’s devicetree to describe GPIO signals. The first element &gpio0 refers to the GPIO port (“port 0” has been selected in the example shown). The second element is the pin number on that port. The last element must be GPIO_ACTIVE_HIGH for nRF21540, but for a different FEM module you can use GPIO_ACTIVE_LOW.

The state of the remaining control pins should be set in other ways and according to nRF21540 Product Specification.
On nRF53 devices, you must also apply the same devicetree node mentioned in step 1 to the network core. To do so, apply the overlay to the correct network core child image by creating an overlay file named child_image/*childImageName*.overlay in your application directory, for example child_image/multiprotocol_rpmsg.overlay.

The *childImageName* string must be one of the following values:
- multiprotocol_rpmsg for multiprotocol applications having support for both 802.15.4 and Bluetooth.
- 802154_rpmsg for applications having support for 802.15.4, but not for Bluetooth.
- hci_rpmsg for application having support for Bluetooth, but not for 802.15.4.
Note

This step is not needed when testing with Bluetooth: Direct Test Mode and Radio test on the nRF53 Series devices.

SPI/GPIO mode 

The nRF21540 features an SPI interface. You can use it to fully control your front-end module or you can use a combination of SPI and GPIO interface. The SPI interface enables you, for example, to set the output power of the nRF21540.

To use nRF21540 in SPI or mixed mode, complete the following steps:

Add the following node in the devicetree file:

/ {
      nrf_radio_fem: name_of_fem_node {
         compatible  = "nordic,nrf21540-fem";
         tx-en-gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
         rx-en-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
         pdn-gpios   = <&gpio0 15 GPIO_ACTIVE_HIGH>;
         spi-if = <&nrf_radio_fem_spi>
   };
};

Optionally replace the device name name_of_fem_node.
Replace the pin numbers provided for each of the required properties:
- tx-en-gpios - GPIO characteristic of the device that controls the TX_EN signal of nRF21540.
- rx-en-gpios - GPIO characteristic of the device that controls the RX_EN signal of nRF21540.
- pdn-gpios - GPIO characteristic of the device that controls the PDN signal of nRF21540.
These properties correspond to TX_EN, RX_EN, and PDN pins of nRF21540 that are supported by software FEM.

The``phandle-array`` type is commonly used for describing GPIO signals in Zephyr’s devicetree. The first element &gpio0 refers to the GPIO port (“port 0” has been selected in the example shown). The second element is the pin number on that port. The last element must be GPIO_ACTIVE_HIGH for nRF21540, but for a different FEM module you can use GPIO_ACTIVE_LOW.

Set the state of the remaining control pins according to the nRF21540 Product Specification.

Add a following SPI bus device node on the devicetree file:

&pinctrl {
   spi3_default_alt: spi3_default_alt {
      group1 {
         psels = <NRF_PSEL(SPI_SCK, 1, 15)>,
                 <NRF_PSEL(SPI_MISO, 1, 14)>,
                 <NRF_PSEL(SPI_MOSI, 1, 13)>;
      };
   };

   spi3_sleep_alt: spi3_sleep_alt {
      group1 {
         psels = <NRF_PSEL(SPI_SCK, 1, 15)>,
                 <NRF_PSEL(SPI_MISO, 1, 14)>,
                 <NRF_PSEL(SPI_MOSI, 1, 13)>;
         low-power-enable;
      };
   };
};

fem_spi: &spi3 {
        status = "okay";
   pinctrl-0 = <&spi3_default_alt>;
   pinctrl-1 = <&spi3_sleep_alt>;
   pinctrl-names = "default", "sleep";
        cs-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;

        nrf_radio_fem_spi: nrf21540_fem_spi@0 {
                compatible = "nordic,nrf21540-fem-spi";
                status = "okay";
                reg = <0>;
                label = "FEM_SPI_IF";
                spi-max-frequency = <8000000>;
        };
};

In this example, the nRF21540 is controlled by the spi3 bus. Replace the SPI bus according to your hardware design.

Create alternative pinctrl entries for SPI3 and replace the pinctrl-N and pinctrl-names properties.

Optional properties 

The following properties are optional and you can add them to the devicetree node if needed.

Properties that control the other pins:
- ant-sel-gpios - GPIO characteristic of the device that controls the ANT_SEL signal of the nRF21540.
- mode-gpios - GPIO characteristic of the device that controls the MODE signal of the nRF21540.
  
  The MODE signal of the nRF21540 switches between two values of PA gain. The pin can either be set to a fixed state on initialization, which results in a constant PA gain, or it can be switched in run-time by the protocol drivers to match the transmission power requested by the application.
  
  To enable run-time MODE pin switching, you must enable CONFIG_MPSL_FEM_NRF21540_RUNTIME_PA_GAIN_CONTROL.
  
  Note
  
  The state of the MODE pin is selected based on the available PA gains and the required transmission power. To achieve reliable performance, CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTA and CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB_POUTB must reflect the content of the nRF21540 registers. Their default values match chip production defaults. For details, see the nRF21540 Product Specification.
  
  If the run-time MODE pin switching is disabled, the PA gain is constant and equal to CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB.
Properties that control the timing of interface signals:
- tx-en-settle-time-us - Minimal time interval between asserting the TX_EN signal and starting the radio transmission, in microseconds.
- rx-en-settle-time-us - Minimal time interval between asserting the RX_EN signal and starting the radio transmission, in microseconds.
  
  Note
  
  Values for these two properties cannot be higher than the Radio Ramp-Up time defined by TX_RAMP_UP_TIME and RX_RAMP_UP_TIME. If the value is too high, the radio driver will not work properly and will not control FEM. Moreover, setting a value that is lower than the default value can cause disturbances in the radio transmission, because FEM may be triggered too late.
- pdn-settle-time-us - Time interval before the PA or LNA activation reserved for the FEM ramp-up, in microseconds.
- trx-hold-time-us - Time interval for which the FEM is kept powered up after the event that triggers the PDN deactivation, in microseconds.
The default values of these properties are appropriate for default hardware and most use cases. You can override them if you need additional capacitors, for example when using custom hardware. In such cases, add the property name under the required properties in the devicetree node and set a new custom value.

Note

These values have some constraints. For details, see nRF21540 Product Specification.

Adding support for Skyworks front-end module 

You can use the Skyworks range extenders with nRF52 and nRF53 Series devices. SKY66112-11 is one of many FEM devices that support the 2-pin PA/LNA interface. The nRF Connect SDK provides also devicetree bindings for the SKY66114-11 and SKY66403-11. You can use SKY66112-11 as an example on how to create bindings for different devices that support the 2-pin PA/LNA interface. For more details about devicetree binding, see: Zephyr documentation.

Note

In the naming convention used in the API of the MPSL library, the functionalities designated as PA and LNA apply to the ctx-gpios and crx-gpios pins listed below, respectively.

To use the Simple GPIO implementation of FEM with SKY66112-11, complete the following steps:

Add the following node in the devicetree file:

/ {
   nrf_radio_fem: name_of_fem_node {
      compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
      ctx-gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
      crx-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
   };
};

Optionally replace the node name name_of_fem_node.
Replace the pin numbers provided for each of the required properties:
- ctx-gpios - GPIO characteristic of the device that controls the CTX signal of SKY66112-11.
- crx-gpios - GPIO characteristic of the device that controls the CRX signal of SKY66112-11.
These properties correspond to CTX and CRX pins of SKY66112-11 that are supported by software FEM.

Type phandle-array is used here, which is common in Zephyr’s devicetree to describe GPIO signals. The first element &gpio0 refers to the GPIO port (“port 0” has been selected in the example shown). The second element is the pin number on that port. The last element must be GPIO_ACTIVE_HIGH for SKY66112-11, but for a different FEM module you can use GPIO_ACTIVE_LOW.

The state of the other control pins should be set according to the SKY66112-11 documentation. See the official SKY66112-11 page for more information.

Optional properties 

The following properties are optional and you can add them to the devicetree node if needed.

Properties that control the other pins:
- csd-gpios - GPIO characteristic of the device that controls the CSD signal of SKY66112-11.
- cps-gpios - GPIO characteristic of the device that controls the CPS signal of SKY66112-11.
- chl-gpios - GPIO characteristic of the device that controls the CHL signal of SKY66112-11.
- ant-sel-gpios - GPIO characteristic of the device that controls the ANT_SEL signal of devices that support antenna diversity, for example SKY66403-11.
Properties that control the timing of interface signals:
- ctx-settle-time-us - Minimal time interval between asserting the CTX signal and starting the radio transmission, in microseconds.
- crx-settle-time-us - Minimal time interval between asserting the CRX signal and starting the radio transmission, in microseconds.
The default values of these properties are appropriate for default hardware and most use cases. You can override them if you need additional capacitors, for example when using custom hardware. In such cases, add the property name under the required properties in the devicetree node and set a new custom value.

Note

These values have some constraints. For details, see the official documentation at the SKY66112-11 page.
Properties that inform protocol drivers about gains provided by SKY66112-11:
- tx-gain-db - Transmission gain value in dB.
- rx-gain-db - Reception gain value in dB.
The default values are accurate for SKY66112-11 but can be overridden when using a similar device with a different gain.

Use case of incomplete physical connections to the FEM module 

The method of configuring FEM using the devicetree file allows you to opt out of using some pins. For example, if power consumption is not critical, the nRF21540 module PDN pin can be connected to a fixed logic level. Then there is no need to define a GPIO to control the PDN signal. The line pdn-gpios = < .. >; can then be removed from the devicetree file.

Generally, if pin X is not used, the X-gpios = < .. >; property can be removed. This applies to all properties with a -gpios suffix, for both nRF21540 and SKY66112-11.

Hardware support 

Two nRF21540 boards are available, showcasing the possibilities of the nRF21540 FEM:

Also, various Skyworks front-end modules are supported. For example, SKY66112-11EK has a 2-pin PA/LNA interface.

The front-end module feature is supported on the nRF52 and nRF53 Series devices.

nRF21540 DK 

The nRF21540 DK is a development kit that features the nRF52840 device combined with the additional nRF21540 front-end module. You can use it the same way as nRF52840 DK. It is an easy way to start testing front-end modules. For more details, see nRF21540 DK.

Shields 

Shields are add-ons that you can attach to the development kit to extend its feature and functionalities.

nRF21540 EK 

The nRF21540 EK (Evaluation Kit) is an RF front-end module (FEM) for Bluetooth Low Energy, Bluetooth mesh, 2.4 GHz proprietary, Thread, and Zigbee range extension. When combined with an nRF52 or nRF53 Series SoC, the nRF21540 RF FEM’s +21 dBm TX output power and 13 dB RX gain ensure a superior link budget for up to 16x range extension.

Overview 

The nRF21540 complementary device has a 50 Ω SMA transceiver interface and 2x 50 Ω SMA antenna interfaces. This enables connecting an SoC or a signal generator to the input. It also enables connecting the outputs to measurement tools or to antennas directly. The FEM can be configured through the pins available on the Arduino headers.

The nRF21540’s gain control, antenna switching, and modes are controlled using GPIO or SPI, or a combination of both. GPIO and SPI are accessible through the Arduino Uno Rev3 compatible headers. The shield also features two additional SMA connectors hooked to the dual antenna ports from the RF FEM, to monitor the performance of the RF FEM using any equipment desired. The FEM SMA input can be connected to the nRF52 or nRF53 Series SoC RF output with a coaxial RF cable with SMASWF connectors.

Pin assignment 

Shield connector pin	SIGNAL	FEM function
D2	GPIO	Mode Select
D3	GPIO	RX Enable
D4	GPIO	Antenna Select
D5	GPIO	TX Enable
D9	GPIO	Power Down
D10	SPI CS	Chip Select
D11	SPI MOSI	Serial Data In
D12	SPI MISO	Serial Data Out
D13	SPI SCK	Serial Clock

Programming 

Set -DSHIELD=nrf21540_ek when you invoke west build or cmake in your Zephyr application.

Alternatively, add the shield in the project’s CMakeLists.txt file:

set(SHIELD nrf21540_ek)

To build with the nRF Connect for VS Code extension, specify -DSHIELD=nrf21540_ek in the Extra Cmake arguments field. See Providing CMake options.

When building for a board with an additional network core, for example nRF5340, add an additional -DSHIELD variable with the childImageName_ parameter between -D and SHIELD to build for the network core as well. For example:

west build -b nrf5340dk_nrf5340_cpuapp -- -DSHIELD=nrf21540_ek -Dmultiprotocol_rpmsg_SHIELD=nrf21540_ek

In this command, the childImageName_ parameter has the multiprotocol_rpmsg_ value and builds a multiprotocol application with support for 802.15.4 and Bluetooth. The childImageName_ parameter can take the following values:

multiprotocol_rpmsg_ for multiprotocol applications with support for 802.15.4 and Bluetooth
802154_rpmsg_ for applications with support for 802.15.4, but without support for Bluetooth
hci_rpmsg_ for application with support for Bluetooth, but without support for 802.15.4

References 

Shields with 2-pin PA/LNA interface 

The SKY66112-11EK is an example of a shield with the 2-pin PA/LNA interface.

Perform the following steps to use it:

Connect the shield to the development kit.
Follow the steps in the Adding support for Skyworks front-end module to add a FEM node in the devicetree.
Build your project.
Program the development kit with the created binary file.