nRF21540 FEM TX Power with ESB

[H. Dekker]

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

According to the Enhanced ShockBurst sample documentation, FEM support is available.
I have modified the standard esb_ptx and esb_prx examples to test the various TX power levels supported by different Nordic boards and to observe the resulting RSSI values on the receiving side. This allows me to test range and determine which Nordic chip or antenna performs best and which TX power level is required for stable communication.

FEM Support:

The modified example works well in general, but I see no improvement when using an nRF21540-DK or any other Nordic board equipped with the nRF21540-EK shield.

I’ve carefully followed all documentation and Q&A posts on Nordic Developer Zone. I have enabled the necessary MPSL drivers and configured the correct overlay settings for FEM support.

However, on the nRF21540-DK, the signal is so weak that I can only transmit packets if the PTX and PRX boards are placed directly next to each other. It doesn’t seem to make a difference whether MPSL is enabled or not.

With other boards like the nRF52840 + nRF21540-EK shield, the received signal is also significantly worse compared to using no FEM at all.

I’ve spent quite some time on this and have a decent amount of experience with the Nordic platform, but I just can’t get FEM to work properly with the ESB protocol using the nRF Connect SDK 3.0.1.

So I’m wondering:

• Am I missing something in the configuration?

• Could there be a software or driver issue?

• Or is there possibly something wrong with the hardware?

I’ve attached my ESB RSSI test project, along with the console output for different Nordic development boards. Feel free to use this example for other purposes—it can be helpful to quickly test RSSI across various boards and antenna setups at different distances.


Sample: ESB-RSSI (version 26-7-2025).zip

[H. Dekker]

Hello Asbjørn,

I’m curious to know if you’ve been able to raise the issue with development yet? I really think something needs to be done about the documentation—it doesn’t match the current situation in several areas and is also very sparsely described.

I’ve been busy testing over the past week. What I found is that the TX output power has to be increased in a different way than what’s documented. I’m currently setting the power using:
esb_set_tx_power(22);
or with
esb_set_tx_power(CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB);
If I don’t do this, the range is less than or equal to the situation without a FEM.

I’m now getting really good range with the nRF21540 FEM. I did an outdoor test today using an nRF21540-DK on the PTX side and was able to reach a distance of over 500 meters with ESB at 1 Mbps and FEM support at 22 dBm. There was no direct line of sight—many trees and even houses were between the transmitter and receiver. The PRX receiver was a basic nRF54L15-DK.

There is still something strange on the PTX side with the nRF21540: the ESB_EVENT_TX gives a failed event at just 5 to 10 meters distance, even though my PRX is receiving the packets correctly. I don’t see this issue when I use, for example, an nRF54L15. So apparently, the nRF21540 is still not properly receiving ACK packets due to insufficient receive gain or configuration.

I also couldn’t get it working on the nRF7002-DK + nRF21540-EK (while it does work on an nRF5340-DK, same SoC). Something goes wrong during the build process—so that’s another bug.

I’ve updated my test example again; see the attachment on the right side (“ESB-RSSI (version 3-7-2025)”).

In short, there are several bugs in the ESB module and also undocumented functionality. This makes it extra complex to work properly with ESB. But if you fix these bugs and update the documentation, it will be a very nice protocol to work with.

Thanks in advance for your response,

Herke Dekker

[Glen M]

Hi Mr. Dekker - I know you are a user like me and not a Nordic employee but it seems like you've figured out a ton on this issue and I'm hoping you can point me in the right direction as I'm stuck.

We started with the nrf5340_audio_dk doing Bluetooth BIS broadcast audio and we spun a custom board with a Fanstel BT40N module (just an nrf5340 with an nrf21540 on a module) with a new codec. I'm using SDK 2.9.1.

I believe I've followed all of the instructions but my receiver barely sees the transmitter a couple feet away and it doesn't work reliably. I get a bunch of sync errors and it disconnects after a few seconds.

Based on what you found here I tried setting my pdn pin in devicetree to an unused pin and then I manually set the real GPIO pin for it to output high in my startup code, but it didn't fix my issue. I don't have physical access to this pin to just solder VDD to it as it's all inside the module.

Could you maybe post a zip file of that nrf5340 project that you got working, or do you have any advice? I think I have my devicetree stuff right and that my issue is in what CONFIG items to put in the app and net cores, though I could be wrong.  My support ticket for reference is HERE

Thanks very much,

Glen

[H. Dekker]

Dear Glen,

I saw your question come in and had a bit of time today to take a look. The Nordic / Zephyr platform is really impressive, and development is progressing rapidly. But the learning curve for this platform is very steep. I'm normally used to making big strides quickly, but with this solution, you quickly learn that slow and steady wins the race. It can be super frustrating to work with the Nordic setup at times. I also sometimes need to blow off some steam when something turns out to be undocumented or there's a bug in the SDK. Sometimes it feels like you're working with a beta product. I often end up diving into the SDK source code to really understand how things work. But once you finally get something working, it's also incredibly rewarding.

A tip I can give: take very small steps and document your own code and changes thoroughly. After a week, you'll have tried so many things that you might not remember what actually worked. Another tip: always start by building your solution using official Nordic DK hardware. Get everything working there first—it's easier to debug. Once that’s working, you can port the code over to your own PCB or a third-party module like Fanstel or Raytec. Nordic can offer less support when you use custom or third-party boards. Just last week, I found two bugs in the devicetree and config of a Raytec module. Took me a couple of days to figure out—just a really dumb bug. The code simply couldn’t run as-is, which makes me wonder how much third-party vendors actually test their modules.

I personally have nearly every Nordic board except the nRF5340_Audio_DK. But I can test things without hardware too. Without FEM, I was able to make a build immediately. But as soon as I activated the FEM via build config with CMake arguments: -DSHIELD=nrf21540ek, I got a build error. I looked into it and it's a bug. As soon as you specify the nRF21540EK shield, Zephyr tries to include the NPM1100 PMIC in the project, which is missing data in the devicetree: “undefined reference to __device_dts_ord_8”. I worked around it by using no-sysbuild. The issue is in the cpuapp part of the build, which remains empty in my ESB project but suddenly pulls in the PMIC from Nordic. After that change, I could build the project again. This allowed me to use the devicetree visual editor to find the PDN pin on the nRF5340_AUDIO_DK with FEM. It’s P1.13, which you need to connect to VDD.

In the new SDK 3.1, which should be released very soon, the bug related to MPSL FEM combined with the ESB protocol has been fixed. But you can also manually patch the current SDK if needed—see the PR: https://github.com/nrfconnect/sdk-nrf/pull/23190

Personally, I don’t think the nRF5340 is one of Nordic’s better SoCs. The dual-core setup is nice in theory but makes everything a lot more complex. The radio part is also pretty bad—it can’t output more than 0 dBm, whereas the old nRF52840 from 8 years ago does way better with 8 dBm. Thankfully, they now have the nRF54L15, which is a fantastic chip. It’s fast and has an excellent radio. So we're currently transitioning everything to the nRF54 series.

I’ve updated and re-uploaded my example code. See: ESB-RSSI (version 26-7-2025).zip on the right. I’ve also included the nRF5340_Audio_DK in it.

Best of luck with your project!

Best regards,
Herke Dekker

 

[Glen M]

Thanks very much for the reply, I'll keep after it!