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 18-06-2025).zip

[Vidar Berg]

Hello,

Thank you for providing the sample projects. From the PTX project I see that you have implemented a function named tx_power_supported() which checks whether the requested output power is supported by the nRF RADIO. However, this does not apply when using the FEM, as the MPSL library will always attempt to achieve the requested output power by adjusting the RADIO TX gain, see TX power split.

Best regards,

Vidar

[H. Dekker]

Hi Vidar,

thanks for your response. This is known to me — as you can see in my code, I add the FEM’s TX power also to the value. So I am taking that into total value. This is purely for reference, and I also include it in the ESB packet so that on the other side I can also see with which TX power value something was sent. But the main issue is that my RSSI value is lower when I activate MPSL.

[H. Dekker]

Dear Asbjørn,
Sorry for my late reply — I was abroad for a while. Today I took some time to make a few photos of the test setup.
Here are the answers to your questions:

Q1: The firmware without FEM works fine.
Q2: I've taken several photos of the test setup — see attachments.
Q3: I have about 20 Nordic boards here, so I can try all possible combinations. I flash the firmware specifically for each configuration. So, in the case of an nRF52840-DK + nRF21540-EK, I enable FEM support in my build. I also see during the build that the nRF21540-EK is detected/activated. However, an nRF52840-DK has much better range without the external nRF21540-EK than with it. The same problem occurs when I attach the nRF21540-EK to an nRF5340-DK or an nRF7002-DK.

For the nRF21540-DK, the range is so poor that the nRF21540-DK only works when I physically hold it right next to another board.

Q4: To ensure a fair comparison, I test all boards at exactly the same distance. I’ve created test setups at 2m, 5m, and 10m distance. On the PRX side, I log all values so I can compare them easily afterward. For all tests, I now always use the same board on the PRX side — in this case, an nRF54L15-DK. I also tried with an nRF21540, but that didn’t help either and only made the tests more complicated. I’ve tried to keep the setup as simple as possible in order to present clear cases to Nordic Support.
Eventually, I also want to equip the PRX with an nRF21540 chip, but that’s the next step — first, I just want to get this part working.

I hope the answers and photos give you a better idea of my test environment. I also hope you’ll have some answers for us soon. We’re currently experiencing significant delays in our project, and at this point, that’s really no longer acceptable. I believe my colleague and I are quite experienced in software development and the Nordic ecosystem — we’re not beginners — and everything else in our project is running smoothly.

I genuinely think there’s a bug in the SDK; otherwise, we’re overlooking something massive — and if that’s the case, then it’s also not well documented. Aside from that, I find the documentation around FEM support to be rather poor — you have to gather bits of information from all over, and some things have already changed again in the latest SDK version.

Thanks in advance for your response.

Best regards,

Herke Dekker

Fullscreen serial-terminal-04062025_140101 (prx nrf54L15).txt Download

*** Booting nRF Connect SDK v3.0.1-9eb5615da66b ***
*** Using Zephyr OS v4.0.99-77f865b8f8d0 ***

Enhanced ShockBurst prx sample
TX Performance test and RSSI value

[PRX] Version: 3 | Build: Jun  2 2025 15:11:19
Board: nrf54l15dk
Device ID: 416016678

FEM RX support: disabled
HF clock started
Initialization complete

Setting up for packet receiption
----------------------
ID:2693870648 | Board:nRF52840DK            | Counter:  0 | TX:  0 dBm | RSSI:-70 dBm (Weak)
ID:2693870648 | Board:nRF52840DK            | Counter:  1 | TX:  2 dBm | RSSI:-67 dBm (Weak)
ID:2693870648 | Board:nRF52840DK            | Counter:  2 | TX:  3 dBm | RSSI:-66 dBm (Weak)
ID:2693870648 | Board:nRF52840DK            | Counter:  3 | TX:  4 dBm | RSSI:-65 dBm (Average)
ID:2693870648 | Board:nRF52840DK            | Counter:  4 | TX:  5 dBm | RSSI:-65 dBm (Average)
ID:2693870648 | Board:nRF52840DK            | Counter:  5 | TX:  6 dBm | RSSI:-65 dBm (Average)
ID:2693870648 | Board:nRF52840DK            | Counter:  6 | TX:  7 dBm | RSSI:-64 dBm (Average)
ID:2693870648 | Board:nRF52840DK            | Counter:  7 | TX:  8 dBm | RSSI:-62 dBm (Average)

ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  0 | TX: 20 dBm | RSSI:-83 dBm (Critical)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  1 | TX: 22 dBm | RSSI:-79 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  2 | TX: 23 dBm | RSSI:-79 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  3 | TX: 24 dBm | RSSI:-79 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  4 | TX: 25 dBm | RSSI:-79 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  5 | TX: 26 dBm | RSSI:-76 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  6 | TX: 27 dBm | RSSI:-76 dBm (Very Poor)
ID:2693870648 | Board:nRF52840DK FEM Active | Counter:  7 | TX: 28 dBm | RSSI:-76 dBm (Very Poor)

ID:0686171830 | Board:nRF5340DK             | Counter:  0 | TX:  0 dBm | RSSI:-69 dBm (Weak)

ID:2628253021 | Board:nRF7002DK             | Counter:  0 | TX:  0 dBm | RSSI:-69 dBm (Weak)

ID:3170380583 | Board:nRF54L15DK            | Counter:  0 | TX:  0 dBm | RSSI:-69 dBm (Weak)
ID:3170380583 | Board:nRF54L15DK            | Counter:  1 | TX:  1 dBm | RSSI:-68 dBm (Weak)
ID:3170380583 | Board:nRF54L15DK            | Counter:  2 | TX:  2 dBm | RSSI:-66 dBm (Weak)
ID:3170380583 | Board:nRF54L15DK            | Counter:  3 | TX:  3 dBm | RSSI:-66 dBm (Weak)
ID:3170380583 | Board:nRF54L15DK            | Counter:  4 | TX:  4 dBm | RSSI:-64 dBm (Average)
ID:3170380583 | Board:nRF54L15DK            | Counter:  5 | TX:  5 dBm | RSSI:-63 dBm (Average)
ID:3170380583 | Board:nRF54L15DK            | Counter:  6 | TX:  6 dBm | RSSI:-62 dBm (Average)
ID:3170380583 | Board:nRF54L15DK            | Counter:  7 | TX:  7 dBm | RSSI:-61 dBm (Average)
ID:3170380583 | Board:nRF54L15DK            | Counter:  8 | TX:  8 dBm | RSSI:-61 dBm (Average)

[Asbjørn]

Hello Herke,

I would agree with you that the information related to the nRF21540 EK is scattered, in some aspects I think we could say the same about all Nordic documentation. It's not perfect and there's room for improvement.

However, on the pictures I noticed something, and I might be seeing the incorrectly, but the output from the nRF52840-DK that you have plugged the nRF21540 onto doesn't seem to be connected. There should be a cable between J1 on the nRF52840-DK and the TRX SMA connector on the nRF21540-EK.

Connector on the nRF52840 is a female type of MM8130-2600 connector onto the male SMA on the EK.

Best regards

Asbjørn

[H. Dekker]

Hi Asbjørn,

Thank you for your response. I’m not sure whether I should feel relieved or completely frustrated. At the very least, I really appreciate your comment.

I’ve been struggling with the nRF21540 for two months now. I’ve already submitted multiple Q&A posts on this topic. At some point, I really started to lose hope. I work with the Nordic platform every day and feel like I have a pretty good grasp on it, but not being able to get the nRF21540 working has been incredibly frustrating. The cable doesn’t solve the issue I’m also experiencing with the nRF21540-DK — that board has a range of just 5 cm (not a typo).

I went through all the Nordic documentation again, including every relevant webpage I could find. Nowhere is it mentioned that you need to bridge the J1 port. I assumed that was only used for lab equipment, like when testing output power with a spectrum analyzer. It’s honestly bizarre that this isn’t documented anywhere. There’s even a schematic showing which pins to enable and which ports to use — but still, no mention of this. Why isn’t there a simple diagram showing how to connect this cable, or a sentence in the text like: "️ Warning: A connection is required between your development board (J1) and this port to include the FEM in your RF path." Why doesn’t Nordic include the cable in the kit? You always need it, and the type of cable is quite specific. Yet even that isn’t documented anywhere.

I’ve now ordered the cable as well as an additional nRF21540-DB kit so I can also check whether the one I already have(nRF21540-DK) might be defective (max range 5 cm).

I should receive the items next week. I’ll test everything immediately and let you know if this solves the issue.

Thanks again!

Kind regards,
Herke Dekker

[Asbjørn]

Hello Herke,

I can feel your frustration and I'll be honest with you, I thought there would be such a statement in the documentation as well that the connection between J1 and TRX was needed. For some it might be obvious, but for others there's nothing indicating that it is needed. I'm sorry you've been struggling with this. I've made a request here to the documentation team to add the sentence about this connection for future updates. 

Let us know how the cable works out, I can't see anything else that could be causing this.

Best regards

Asbjørn

[H. Dekker]

Hi Asbjørn,

I ordered an MXHS83QE3000 cable from Mouser, along with an ADP-SMAM-SMAM-G RF adapter. I couldn’t find another cable with a male SMA connector. I also ordered an extra nRF21540-DB Kit to rule out the possibility of a defective development board. I received the items from Mouser yesterday.

Today, I tested the setup using the cable between an nRF52840-DK and an nRF21540-EK. Unfortunately, the tests show no improvement compared to last week. I still observe around 10 dBm worse reception (my RSSI value is 10 dBm lower) compared to a standard nRF52840-DK board without a FEM.

As soon as I disable the MPSL driver, the reception immediately improves, and the values return to those seen in the standard nRF52840-DK setup.

As far as I can tell, the cable is connected correctly. See attached photo.

I also tested with a standard nRF21540-DK board, of which I now received a second one. On this board as well, the reception is so poor that I can only transmit ESB packets when the boards are just a few centimeters apart.

Working solution:
I continued testing and checked the pin connections between the nRF52840-DK and the nRF21540-EK. It turned out that the PDN pin was never activated, although it should be, as far as I understand. When I manually forced the PDN pin high by connecting it to VDD, I achieved good TX power on the spectrum analyzer. The RSSI value in my ESB example is now 25 dBm higher.

I did the same on the nRF21540-DK, where I previously had almost no output. After also forcing the PDN pin high on that board, it started working properly and I had very good reception on the PRX side.

Conclusion:
The current workaround is to manually force the PDN pin high by connecting it to VDD. However, this is not a proper solution. I assume the hardware is functioning correctly, and—as I have been pointing out for over six months through multiple support requests—this confirms that there is indeed a bug in the Nordic Connect SDK versions 2.8.0, 2.9.0, and later.

Tip:
I recommend updating the documentation to clearly state that an additional cable is required to connect the nRF21540-EK. I also strongly suggest including this cable in the box by default, as it is quite difficult to find the correct one online. If you choose not to include a cable, please at least specify the exact type needed (brand and part number).

Question:
Can Nordic fix this bug in the Nordic Connect SDK as soon as possible?

Thanks in advance,

Herke Dekker

Photo 1: nRF52840-DK + nRF21540-EK (with wire connecting PDN to VDD)


Photo 2: nRF21540-DK (with wire connecting PDN to VDD)