nRF21540 FEM TX Power with ESB

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: 8546.ESB-RSSI (version 04-06-2025).zip

Parents
  • 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

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

  • This is the code I'm looking at:

    And as far as I can tell, the line esb_set_tx_power() will only be reached when txpower is set to a value supported by the RADIO.

  • I’m taking the radio TX power of the nRF5xxx and the nRF21xxx into account — you can see that I sum these values later on. This is the only way to calculate the total TX power. I’m using a loop to test various radio TX power levels. On the PRX side, you can then see which TX power is needed to send ESB packets reliably over a certain distance. So you can increase the distance and see which nRF configuration allows successful packet transmission. This works well and is stable.

    At the top of mail.c in the PRX example, you can also adjust the range within which you want to test. I’ve currently set it from 0 dBm to 10 dBm. I do check whether each TX power level can be used without causing errors during the test. For the FEM, I’m leaving the power at its default value in this demo, but it can be adjusted in fem.conf.

    My point is that the range becomes worse when using an nRF21540, even though it’s supposed to improve the range. The actual TX power I calculate isn’t that important — the key issue is which packets actually arrive at the PRX. And that’s a real problem when I activate the nRF21540 FEM — both with the nRF21540-EK and the nRF21540-DK.

    With the example I attached, you can clearly see this.

    Now the question is: am I doing something wrong in how I control the nRF21540? Is there something off in the Nordic Connect SDK 3.0? Or am I dealing with multiple faulty Nordic development boards?

    Thanks in advance for your response,

Reply
  • I’m taking the radio TX power of the nRF5xxx and the nRF21xxx into account — you can see that I sum these values later on. This is the only way to calculate the total TX power. I’m using a loop to test various radio TX power levels. On the PRX side, you can then see which TX power is needed to send ESB packets reliably over a certain distance. So you can increase the distance and see which nRF configuration allows successful packet transmission. This works well and is stable.

    At the top of mail.c in the PRX example, you can also adjust the range within which you want to test. I’ve currently set it from 0 dBm to 10 dBm. I do check whether each TX power level can be used without causing errors during the test. For the FEM, I’m leaving the power at its default value in this demo, but it can be adjusted in fem.conf.

    My point is that the range becomes worse when using an nRF21540, even though it’s supposed to improve the range. The actual TX power I calculate isn’t that important — the key issue is which packets actually arrive at the PRX. And that’s a real problem when I activate the nRF21540 FEM — both with the nRF21540-EK and the nRF21540-DK.

    With the example I attached, you can clearly see this.

    Now the question is: am I doing something wrong in how I control the nRF21540? Is there something off in the Nordic Connect SDK 3.0? Or am I dealing with multiple faulty Nordic development boards?

    Thanks in advance for your response,

Children
No Data
Related