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 3-7-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.

[Asbjørn]

Hello Herke,

Vidar asked me to have a look at your questions as the description of "signal so weak that I can only transmit packets if the PTX and PRX are placed directly next to each other". This is the same behaviour I would expect if for some reason the antenna on one (or both) of the boards was missing. The matching network and board itself will radiate enough that it will be transmit a very short distance.

Q1: The FW without the FEM works ok, if I understand you correctly?

Q2: Could you send a picture of the actual PTX and PRX boards and setup you are using? 

Q3: Are you manually connecting the FEM between the non-FEM tests and the tests with FEM?

Q4: It sounds like you have several boards available, what RSSI readings are you actually seeing on the PRX when you are not using the FEM and at what distance would that be? How does this change when you add the FEM with same distance and location?

I suspect there's something with the connection that is causing this based on the description. If you are able to get packets through at very short distances with FEM and "normal" 10-20meter range when there's no FEM, with the same FW, I'd check the connections through the FEM. If you have a FEM on both sides, I'd debug with just one side first to see if it's the PRX or PTX to narrow it down.

Best regards

Asbjørn

[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)

[Asbjørn]

Hello Herke,

Based on your experiences there will be an update to the nRF21540-EK out shortly with better figure and the part number for the cable that is needed.

Regarding the PDN bug, I will try to recreate this observation here and report it to our development team as a bug. It should certainly be corrected and not sure how it could have gone undetected for a few SDK releases.

Thank you for your feedback and I hope the evaluation goes better from here on out. I'll let you know when the update to SDK would be scheduled if you are interested.

Best regards

Asbjørn

[H. Dekker]

Hello Asbjørn,

Glad the bug has been identified. I can imagine that this issue only occurred when using the ESB protocol, which is why it might not have been immediately noticed—most people probably use standard Bluetooth by default.

FEM support on an nRF5340-DK and nRF7002-DK:
I’m currently testing FEM support for ESB on both the nRF5340-DK and the nRF7002-DK. On the nRF5340-DK it works right away, but I’m not getting any extra range, which is strange.

However, on the nRF7002-DK I can’t get MPSL to work. I’m just using the same example I used previously. It’s odd, because both boards use the same nRF5340 SoC. So I think I might have found another bug.

Thanks in advance,

Herke Dekker

[H. Dekker]

Hello Asbjørn,

I’ve been doing some further testing with the nRF21540 FEM. As I mentioned earlier, the nRF21540-EK does not work with the nRF7002-DK, but it does work fine with the nRF5340-DK. I’m still investigating what’s going wrong here, but it seems to be a driver or SDK issue, since I get a compile-time error as soon as I switch my board from the nRF5340-DK to the nRF7002-DK in my MPSL integration.

Today I came across another strange behavior, and I’m not sure if this is also an SDK bug. From what I understand from the documentation and DevZone articles, I configure the FEM TX gain using the option CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=20, and then I set the base TX power on, for example, the nRF52840-DK using esb_set_tx_power(ESB_TX_POWER_8DBM);. These values together should form the total TX output power.

However, in practice, the output power from the nRF52840-DK alone seems about the same as with the nRF21540-EK connected, when I use esb_set_tx_power(ESB_TX_POWER_8DBM);. I can confirm this by checking the RSSI on my ESB-PRX, and I expected a stronger signal with the FEM.

Just out of curiosity, I tried increasing the TX power manually using esb_set_tx_power(10);, and I immediately noticed a better RSSI. I continued increasing it step-by-step, up to esb_set_tx_power(21);, and now I’m seeing about 20 dBm better RSSI, which is more in line with what I expected from the FEM.

I haven’t seen any documentation suggesting that values above ESB_TX_POWER_8DBM are valid for the nRF52840, since those enums don't even exist—but it turns out that manually passing a higher integer does increase the TX power. The RSSI at level 21 seems to reflect the added gain from the FEM as expected.

So my question is: am I using some undocumented functionality here? Is this a bug in how TX power is being applied? Or is Nordic in the process of changing how FEM power control works in the SDK 3.x series, and it's simply not documented yet?

Thanks in advance for your response.

Best regards,

Herke Dekker

[JPhilippe]

Hello Herke,

I have also been working on the ESB + nRF2154 issue. Taking into account all of your previous comments I have come to the following conclusion:

Actually, it's as simple as pie!!! >>> When an nRF21540 FEM is present, the antenna power is determined by the parameter passed to the esb_set_tx_power() function; esb_set_tx_power(22) gives the best result.

Everything specified in prj.conf must be consistent for this to work.

I used your esb_prx application and modified esb_ptx slightly to confirm the result.

Best regards from Brittany in France,

Jean Philippe Glesser