Interfacing nRF21540 with nRF52832 Using nRF Connect SDK

[Embel_Tech]

Hello Team,          

          I am currently working with the nRF52832 and using the nRF Connect SDK (NCS) with toolchain version 2.9.1. I would like to interface the nRF21540 RF Front-End Module with the nRF52832.

      However, based on the documentation, I could not find any specific examples or detailed steps for this particular interface. Could you please provide reference documents or guidance on how to properly interface the nRF21540 with the nRF52832?

   If possible, I would appreciate a step-by-step outline including any dependencies or configuration requirements necessary to get the setup working correctly with the nRF Connect SDK.

  Looking forward to your support.

[Hieu]

Hello Embel_Tech,

Please find documentation on how to work with the nRF21540 FEM here: Developing with Front-End Modules.

Hieu

[Embel_Tech]

Thanks for your response, will check.

[Embel_Tech]

Hi Hieu,

     I am working with the nRF52832 as a central device using the nRF5 SDK 15.0.0, and we are trying to interface the nRF21540 (EK) board with the nRF52832 specifically for RX gain enhancement only.

     According to the nRF21540 documentation, the RX gain is fixed at +13 dBm. Since this is a central device, we do not intend to use TX control. for RX gain Our hardware setup is as follows:

nRF52832 Pin	nRF21540 EK Pin
VDD	VDD
GND	GND
P0.03	RX_EN
P0.04	PDN (P10.2)

     The antenna is connected to ANT1 on the nRF21540, and the antenna output from the nRF52832 is connected to the TRX input on the nRF21540 EK.

Software Implementation:

• Configure RX_EN and PDN GPIOs as outputs and keep them set high continuously. Because the nRF52832 is running in continuous scanning mode as a central device.

Observed Behavior:

    We tested device advertising at approximately -40 dBm RSSI. When the central and peripheral devices are very close (around 40-50 cm), scanning works successfully. However, when the distance increases slightly, the device is not detected/scanned.

Questions:

1. Is the interfacing of the nRF21540 with the nRF52832 using nRF5 SDK 15.0.0, as described above, correct? Are we missing any critical hardware or software configurations?

2. What could be the possible reasons or missing steps that might cause the range extender to not function as expected?

Any insights or suggestions would be greatly appreciated.

Thank you!

[Hieu]

Hi Embel_Tech,

Embel_Tech said:

Is the interfacing of the nRF21540 with the nRF52832 using nRF5 SDK 15.0.0, as described above, correct? Are we missing any critical hardware or software configurations?

Aside from the 4 pins you detailed, have you also pulled the other pins to VDD or GND appropriately?

Also, is there a reason you changed from using NCS v2.91 to using nRF5 SDK v15.0.0?

Embel_Tech said:

What could be the possible reasons or missing steps that might cause the range extender to not function as expected?

Are you performing active scanning or passive scanning?

You use the terms central and peripheral. Is the central device initiating a connection?

[Embel_Tech]

Hello Hieu,

1]

     We are using the nRF52833 as a scanner in our final product. Product development has been completed, with the exception of range extender (nRF21540) interfacing. As of now, we are using the nRF5 SDK v17.1.0 for firmware development and for nRF52833 Support.

     For the nRF21540 range extender integration, we are currently not using any built-in library or API support. Instead, we are testing the basic GPIO-based control manually. The GPIOs have been defined and configured as follows:

nrf_gpio_cfg_output(TXEN_PIN); // P0.03 defined as output pin nrf_gpio_cfg_output(RXEN_PIN); // P0.28 defined as output pin nrf_gpio_cfg_output(PDN_PIN); // P0.20 defined as output pin nrf_gpio_cfg_output(MODE_PIN); // P0.29 defined as output pin nrf_gpio_cfg_output(ANT_SEL_PIN); // P0.02 defined as output pin nrf_gpio_pin_clear(TXEN_PIN); // TXEN inactive (TX gain disabled) nrf_gpio_pin_set(RXEN_PIN); // RXEN active (RX gain enabled) nrf_gpio_pin_set(PDN_PIN); // Power up nRF21540 (enabled for RX gain) nrf_gpio_pin_clear(MODE_PIN); // MODE low (TX gain = +20 dB) nrf_gpio_pin_clear(ANT_SEL_PIN); // ANT_SEL low (ANT1 selected)

We would like to confirm:

a] Is this the correct way to enable the nRF21540 in GPIO control mode, particularly for enabling RX gain operation?

b] Is it mandatory or recommended to use the official libraries or FEM support in the SDK for proper operation, if yes provide correct way to enable nrf21540, or is GPIO-only control sufficient for basic functionality? 

     

 2]   We are using active scanning and nrf52833 will initiates the connection.

   Any guidance on proper usage or required sequence for activating RX/TX gain using GPIOs would be appreciated.

[Hieu]

Hi Embel_Tech,

Embel_Tech said:

 2]   We are using active scanning and nrf52833 will initiates the connection.

   Any guidance on proper usage or required sequence for activating RX/TX gain using GPIOs would be appreciated.

You have to remember that the nRF21540 FEM has RX and TX modes. 
Each mode has to be enabled appropriately when the antenna is transmitting or receiving. Refer to: Operational states.
Note here that when the nRF21540 is in RX mode, TX path is disabled, and vice versa.
This means that if the nRF21540 is locked in RX mode, transmit will not work normally.

Another thing to consider is, the mode has to be enabled well before the antenna start to transmit or receive, because transitioning between modes isn't instant. Refer to: State transition timing.

When the device both transmits and receives, the full range extending effect is only achieved when the modes are switched properly.
A scanner both transmits and receives if it is performing active scanning.
A central always both transmits and receives.

Therefore,

Embel_Tech said:

nrf_gpio_cfg_output(TXEN_PIN); // P0.03 defined as output pin nrf_gpio_cfg_output(RXEN_PIN); // P0.28 defined as output pin nrf_gpio_cfg_output(PDN_PIN); // P0.20 defined as output pin nrf_gpio_cfg_output(MODE_PIN); // P0.29 defined as output pin nrf_gpio_cfg_output(ANT_SEL_PIN); // P0.02 defined as output pin nrf_gpio_pin_clear(TXEN_PIN); // TXEN inactive (TX gain disabled) nrf_gpio_pin_set(RXEN_PIN); // RXEN active (RX gain enabled) nrf_gpio_pin_set(PDN_PIN); // Power up nRF21540 (enabled for RX gain) nrf_gpio_pin_clear(MODE_PIN); // MODE low (TX gain = +20 dB) nrf_gpio_pin_clear(ANT_SEL_PIN); // ANT_SEL low (ANT1 selected)

We would like to confirm:

a] Is this the correct way to enable the nRF21540 in GPIO control mode, particularly for enabling RX gain operation?

If the goal is to enable only RX mode with the LNA, then yes, that is OK.
It keeps the nRF21540 forever powered-on and in RX mode, so the FEM will consume a lot of power, but it will work.

However, if the goal is to extend the range, then no, this is not correct.

This setup works at most with passive scanning only, no connection. 
As you are planning to use active scanning and connection, this will not work.

Embel_Tech said:

b] Is it mandatory or recommended to use the official libraries or FEM support in the SDK for proper operation, if yes provide correct way to enable nrf21540, or is GPIO-only control sufficient for basic functionality? 

The nRF21540 control implementation must be able to track radio activity precisely and enable the TX or RX mode at least early enough before the antenna starts transmitting/receiving

That's the reason why official libraries are not mandatory, but highly recommended.

There is no nRF21540 support on the nRF5 SDK, however. It is only available on NCS.

[Embel_Tech]

Hello Hieu,

     We are developed a BLE-based application using a custom board built around the nRF52833 SoC, operating in the central role for our final product.

    In our implementation, the central scans for BLE peripheral devices and initiates a connection only when a specific custom service UUID is detected in the advertising packet. Upon successful connection, the central performs service and characteristic discovery. Once discovery is complete, the central sends a data request command by subscribing to the appropriate characteristic.

   Following a successful subscription, the peripheral transmits up to 1KB of data. After verifying that all data has been received, the central writes back the current epoch time to the peripheral, which triggers the peripheral to send the next data update.

  This process involves bidirectional communication within a short interval, requiring the radio to switch from RX to TX (for sending subscription/write commands) and from TX to RX (for receiving data) in quick succession—twice per cycle.

Our query:
  Could you please confirm the exact time required for the nRF52833 to switch between RX and TX gain modes (and vice versa) in this type of BLE communication scenario?

   This information is critical for optimizing our communication timing and ensuring reliable data exchange between central and peripheral devices.

   

   Additionally, we would like to understand the correct method for configuring and using the CONFREG0, CONFREG1, CONFREG2, and CONFREG3 registers to control or adjust the TX gain during operation.

    While we have reviewed the available documentation, the usage of these registers for setting different TX gain values remains unclear. We would appreciate your support in confirming the following:

1. The purpose and function of each CONFREG (0–3) in the context of TX gain configuration.

2. The correct procedure to write or map different TX gain values using these registers.

3. Any relevant timing, constraints, or hardware-specific considerations when switching gain levels during active communication (e.g., before or after transmission events).

4. Whether dynamic TX gain adjustments (on a per-packet basis or based on RSSI feedback) are supported using these registers.

5. If any SDK APIs or examples are available for implementing this functionality.

 

   Please let us know if any additional technical details are required from our end.

   Thank you for your support.

[Hieu]

HelloEmbel_Tech,

First of all, I would like to emphasize again that we do not recommend implementing your own nRF21540 FEM control on the nRF5 SDK, because full support for it is available in the nRF Connect SDK. This implementing job is not trivial; and you seem to show interest in the GPIO + SPI control method, which is even more complicated that the GPIO only control that you already are attempting.

Embel_Tech said:

If any SDK APIs or examples are available for implementing this functionality.

As mentioned in my last reply, there are no support for using the nRF21540 with BLE in the nRF5 SDK. That means no API and no examples.

We strongly recommend you use the nRF Connect SDK (NCS) for this.

Embel_Tech said:

Whether dynamic TX gain adjustments (on a per-packet basis or based on RSSI feedback) are supported using these registers.

I don't have the answer for this. However, could you please first consider the recommendation to switch to NCS?

I can raise an internal inquiry if you for some reason are bound to the nRF5 SDK.

Embel_Tech said:

Could you please confirm the exact time required for the nRF52833 to switch between RX and TX gain modes (and vice versa) in this type of BLE communication scenario?

This is clearly mentioned in the Operational States section of the datasheet, as I have explained in my last reply.

Embel_Tech said:

Additionally, we would like to understand the correct method for configuring and using the CONFREG0, CONFREG1, CONFREG2, and CONFREG3 registers to control or adjust the TX gain during operation.

While we have reviewed the available documentation, the usage of these registers for setting different TX gain values remains unclear.

First, we need to keep in mind that the nRF21540 supports two control method. 1. GPIO. 2. GPIO + SPI.

The registers are only relevant in the 2nd control method, GPIO + SPI.

Embel_Tech said:

The purpose and function of each CONFREG (0–3) in the context of TX gain configuration.

In GPIO + SPI mode, writing to the TX_EN or RX_EN bit of the CONFREG registers replace setting the TX_EN or RX_EN pin in GPIO mode.

Other than this,the features that the registers served are explained in the Device control and the SPI interface section of the datasheet.