nRF21540 FEM Not Improving Range in ESB Project (NCS 2.9 / 3.0.1)

[H. Dekker]

We are currently working on a project based on Enhanced ShockBurst (ESB) and would like to use Front-End Module (FEM) support with the nRF21540.

In your Enhanced ShockBurst samples, you mention that there is support for the nRF21540 FEM. The Enhanced ShockBurst (ESB) documentation states:
“ESB requires the MPSL library for front-end module support. This library is always linked into the build, however, it is not initialized by default to provide your application and the ESB protocol with access to all hardware resources. See MPSL FEM-only configuration for more details.”

We have been testing the esb_ptx and esb_prx examples for a week now. We're evaluating the range of different setups using the nRF52840, the nRF21540-DK, and the nRF52840 with the nRF21540-EK.
We made a small modification to the esb_prx source code to read and log the RSSI value directly when a packet is received.

We are following the instructions provided in the Enhanced ShockBurst documentation. During build time, we can see confirmation that the FEM configuration is recognized. For example:

• With the nRF21540-DK: -- Board: nrf21540dk, qualifiers: nrf52840

• With the nRF52840 + nRF21540-EK: -- Shield(s): nrf21540ek

However, we are not observing any improvement in range when using the nRF21540, neither in transmission nor reception. In your blog and documentation, you mention that the FEM can significantly extend the range, even up to 8x.

We’ve reviewed various blogs and Q&A threads, but due to many recent changes in the SDK, we’ve lost track of the correct procedure. Most resources are based on older SDK versions and no longer apply.

We have a few specific questions:

Q1: We are only using ESB (not Bluetooth). Do we need to explicitly initialize MPSL in our code to enable FEM functionality?

Q2: Should I see additional log output at startup when MPSL is active? Right now, this is all we see:

*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
[00:00:00.259,063] <inf> esb_prx: Enhanced ShockBurst prx sample
[00:00:00.266,052] <dbg> esb_prx: clocks_start: HF clock started
[00:00:00.272,857] <inf> esb_prx: Initialization complete
[00:00:00.278,930] <inf> esb_prx: Setting up for packet reception
[00:06:10.058,044] <dbg> esb_prx: event_handler: Packet received, 0xde, RSSI: 79 dBm
[00:06:14.964,416] <dbg> esb_prx: event_handler: Packet received, 0x0f, RSSI: 79 dBm
[00:06:15.164,001] <dbg> esb_prx: event_handler: Packet received, 0x11, RSSI: 78 dBm

Q3: How can we properly increase the TX output power? We’ve come across many examples, but are unsure which ones are correct for SDK v2.9 / 3.0.1.

Q4: How can we improve reception quality? Ideally, we want to use the nRF52840 + nRF21540-EK with an external antenna. Do we need to manually activate the LNA for this?

Q5: It would be very helpful if the ESB documentation or samples included more detailed instructions about FEM configuration, especially regarding what is required vs optional. A lot has changed in the SDK over the past years, and many online examples no longer work with SDK v2.9 / 3.0.1.

[Kazi Afroza Sultana]

Hello,

I have feedback from team 

Answering the questions:

Q1: No, the FEM module in MPSL can work without the MPSL scheduler and this is how it is used in the ESB, so no separate initialization is required in the application code.

Q2: This relates to Q1 a bit. Since no MPSL scheduler is started, there will be no specific log from MPSL if only the FEM module is used

Q3: It should be done through the esb_set_tx_power() function: https://docs.nordicsemi.com/bundle/nrf-apis-latest/page/group_esb_ga63a3c3e672521b5d7646f45331395e95.html#ga63a3c3e672521b5d7646f45331395e95

Q4: The FEM driver integrated sets up the LNA automatically. You just need to build the application with the nRF21540 EK as described in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/fem/21540ek_dev_guide.html.

Q5: FEM are supported in ESB through the integration with the FEM driver in MPSL however without running the MPSL scheduler. We don't have a dedicated sample to show such  setup. In theory the existing samples, when built for a configuration with FEM e.g. on nRF52840 DK + nRF21540 EK should work out of the box.

[H. Dekker]

Dear Kazi,

Thank you for your quick response and for answering the five questions from my initial message. These points are now clear to me. At this point, I practically know the referenced documentation by heart.

We’ve been working daily with the ESB protocol for several months now, and our project is progressing well. We have full control over the ESB part — with the exception of the FEM module, which remains problematic.

To keep things as simple and isolated as possible, we are using the official ESB example from your SDK as the basis for our tests — specifically the esb_ptx and esb_prx samples from nRF Connect SDK v3.0.1. To evaluate signal strength and the effect of transmit power, we made only minor changes to the sample. We added a loop that cycles through all supported TX power levels for the given board and sends that to the PRX side. This allows us to easily test various Nordic development boards, which we have in large supply.

Here’s the issue:
As soon as we activate the FEM module by enabling the appropriate MPSL options in prj.conf and setting -DSHIELD=nrf21540ek, or by selecting a board with integrated FEM like the nRF21540-DK, the transmit power immediately drops, even when we explicitly set it to the maximum via esb_set_tx_power(). The resulting RSSI on the receiver side is consistently worse.

Option 1:

Could your team try the default esb_ptx and esb_prx samples with FEM enabled on your end, and confirm whether higher TX power levels actually lead to improved RSSI? If so, would you be willing to share the exact example setup that works?

Option 2:

Alternatively, we can share our modified esb_ptx and esb_prx samples with you, so you can test them directly and see if anything in the code or configuration might be preventing the FEM from operating correctly.

Depending on your findings, we’re also happy to review the documentation related to FEM + ESB together to check for possible inaccuracies — or even a potential bug in the SDK.

Kind regards,
Herke Dekker