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,

Enabling any FEM into the build by itself will not automagically cause that the greater output power is used. This is true for all protocols. If the protocol requested for example 0 dBm then with FEM it will be still 0dBm but achieved in a different way. The protocol driver needs to ask for more power.

[H. Dekker]

Dear Kazi,

I understand that if I don’t configure additional TX power, I shouldn’t expect significantly better performance.

I’m not new to Nordic Semiconductor products. I’ve been working with them daily for over a year now. We've already built several interesting projects and even developed our own custom boards, so I believe I have a solid understanding of how things work.

The only area I’m really struggling with is FEM support. I’ve tested everything again using the ESB samples with Nordic Connect SDK 3.0.1 (we’ve migrated all our internal projects to the latest SDK). However, I just can’t get it to work properly.

As soon as I enable MPSL in my project (as described in the documentation, including your note about CONFIG_MPSL_FEM_NRF21540_RUNTIME_PA_GAIN_CONTROL=y) and correctly set the board target to something like the nRF52840 + nRF21540-EK (via the CMake flag -DSHIELD=nrf21540ek), the transmission range drops significantly. I’ve also tried adjusting the TX power settings, but the range remains very poor. I tested with the nRF21540-DK as well and encountered exactly the same problem.

When I build the ESB-PTX sample with the default settings for the nRF52840-DK (without FEM), the transmission range is noticeably better.

I should also mention that the documentation for FEM support in the ESB sample isn’t entirely accurate. If you're using a standard nRF21540 or any nRF device with the nRF21540-EK front-end module, there’s no need to manually create an overlay file—this is handled automatically unless you're using a custom board. The current documentation is a bit confusing in that regard. Additionally, there's no clear guidance on what project or code settings are required to actually enable FEM support and benefit from the increased TX and RX range.

I’m seriously starting to doubt whether FEM support is working properly with the ESB protocol. Could you please test this yourself using the standard ESB sample, a nRF21540-DK, and an nRF device with the nRF21540-EK? I’d be very interested to hear whether it works correctly on your side.

It’s possible I’m overlooking something small, but I’ve read nearly every Q&A thread on DevZone related to FEM support and ESB. If you do manage to get it working, could you please share your (modified) ESB sample with me and others on DevZone? Also, please consider updating the documentation to make this process clearer for everyone else. The many changes to the SDK over the past two years haven’t made things easier—especially when trying to follow older DevZone threads.

I really hope this issue will now be taken more seriously and addressed more quickly. It’s been almost two months, and I still haven’t received a solid answer.

Thanks in advance for your feedback and example.