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: ESB-RSSI (version 3-7-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.

  • 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

  • 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

  • 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

  • Hello Jean,

    Thanks for your response. Great to hear that you’ve come to the same conclusion. It indeed works differently than described in Nordic’s documentation. The documentation is already quite lacking—especially with all the changes in the SDK over the past year, which are not always reflected properly.

    I’ve updated my example a bit. It’s not very clean or well-programmed, but it does provide insight into how the ESB protocol is controlled and what the effects are of certain settings. Nordic’s standard ESB example is really minimal and doesn’t give you much of a feel for its possibilities.

    I’m still struggling with reading the current raw TX power using the function nrf_radio_txpower_get(NRF_RADIO); and have implemented a less elegant workaround just to make it clear what power level is being used. At this point, it’s still unclear to me which TX power level the nRF5x uses to transmit and how much is added by the FEM. It seems the base level is 0 dBm and the rest is added by the FEM. I don’t want to spend too much time on this since it’s not critical, but still—another issue that doesn’t sit quite right in Nordic’s SDK.

    I’ve also added a repeat function, so I can place the PTX at a fixed spot and walk around with the PRX to measure how far the signal reaches at a given dBm value. This is a nice way to determine real-world range.

    I’ve re-uploaded the new ZIP file(see attachments on the right panel) for this case so others can benefit from it too. Let’s hope Nordic comes out with a fix soon for the PDN issue—since the PDN pin is not set to HIGH by default, you currently have to power it manually with VDD to get the nRF21540 working at all.

    I also haven’t been able to get the nRF21540-EK working with the nRF7002-DK—this also seems to be a bug or driver issue. It does work on an nRF5340-DK, which has the same SoC. I’ll see if I can get to the bottom of it, or else Nordic needs to fix that soon as well.

    Best regards from North Holland in the Netherlands,

    Herke 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-DK (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

Reply
  • 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-DK (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

Children
No Data
Related