How to integrate radio front end module with Zephyr BLE Controller?

[Jeff Gregorio]

Hello, I’m writing for the UBlox Nora B126, which has an nRF5340 and a Skyworks SKY66405-11 front-end module (FEM). I’m using NCS 2.4.2.

Although I’m able to do simple things from the application core like configure two GPIOs to turn the FEM on and off, this way consumes a prohibitive amount of power, as it doesn’t provide tight enough synchronization with radio usage. I need the FEM to be as soon as the radio starts driving the antenna, and off as soon as it’s done.

I see there’s some documentation on integrating FEMs with MPSL, but I’ve already built a project around the Zephyr BLE Controller using HCI RPMsg sample on the network core. If memory serves, there was some direction finding feature we needed that the SoftDevice under MPSL didn’t support, but I could be mistaken. At any rate I’d like to avoid switching BLE controllers if at all possible.

There’s the Direct support section of these docs that says I don’t need to use MPSL, only set CONFIG_MPSL=y and CONFIG_MPSL_FEM_ONLY=y (I’m also adding CONFIG_MPSL_FEM_SIMPLE_GPIO=y), but the two links for further information in that section are unhelpful.

• The first link to the Front-end module feature docs doesn’t give any info in implementation (configs, device tree overlays for GPIO forwarding, bindings, etc.) so I have no idea how to set it up or what API calls to make.
  
  
• The link to the example Bluetooth: Direct Test Mode (along with the other one given in the MPSL docs, Radio test (short-range)) show a very different implementation of FEM control that doesn’t appear to use any MPSL configs at all. These two examples use the FEM abstraction layer with CONFIG_FEM_AL_LIB=y, and I’m unclear on how its functions know which GPIOs to use for switching—are they somehow using the GIPOs specified in the gpio_fwd item in the device tree overlays? That would be child_image/remote_shell/boards/nrf5340dk_nrf5340_cpuapp.overlay in the direct test example, and conf/remote_shell/pin_fwd.dts in the radio test example.
  
  Also, if I understand these examples correctly, their source code runs on the network core, and they use a child image for the application core, right? If that’s case it sounds like to use the FEM with my project in this way, I’d be modifying HCI RPMsg with a device tree overlay to forward GPIOs for switching, and modifying source code to use the FEM_AL methods… but then I have no idea whether/how I’m supposed to set TX power or anything from the application core.

The section Adding support for Skyworks front-end module shows an example of a device tree node representing the FEM and its CTX/CRX pins, but is this supposed to be defined for the application or network core? And what API do I use this node with in order to control the transmission power?

Is it even possible for me to use the MPSL FEM feature while still using the Zephyr BLE Controller via the HCI RPMsg image for the network core, or do I need to modify HCI RPMsg with calls to the FEM_AL methods similar to the two examples? Should I be using FEM_AL at all, or is this just a complete alternative to the higher-level FEM integration methods described in the docs?

If you have a step-by-step description of how to integrate the FEM on an application core and a network core running hci_rpmsg with all the necessary configs, overlays, code snippets, etc. or if there’s an example I missed showing this approach please feel free to ignore any questions above that are irrelevant.

Many thanks

[Kazi Afroza Sultana]

Hello,

Thanks for your queires. There are several things here need to look at to give you a proper answer. I will try to give one by one. Just before that my initial comment is - MPSL should be used only with SoftDevice Controller or without any BLE controller. Could you please explain why do you want to integrate MPSL with zephyr (when Zephyr seems to have support for FEM)? 

Thanks.

BR

Kazi

[Jeff Gregorio]

Hi, unless I misunderstood the docs I linked, they only go into two ways of configuring the FEM: 1) using MPSL and the SoftDevice controller, and 2) using the radio directly (per the two examples Direct Test Mode and Radio Test) with neither Soft Device nor Zephyr BLE Controller.

I'm not trying to switch to MPSL, I'm just failing to see how any of this documentation applies to FEM integration with the Zephyr controller. I'm also a little confused by the "Direct support" section that says to enable the MPSL-related configs even if you're not using MPSL.

Is there some other documentation on using a FEM with Zephyr Controller and hci_rpmsg that I've been unable to find?

Thanks

[Kazi Afroza Sultana]

Hello,

I have some feedback from the developer.

Problem statement

You want to run Zephyr BLE Controller with support for SKY66405-11 front end module on nRF5340. The problem you are facing is that Zephyr doesn't have out-of-the-box support for such front end module. On the other hand, NCS provides support for several Skyworks front end modules. While SKY66405-11 is not among them, it's trivial to adapt the existing code to support SKY66405-11. However, the support for these front end modules in NCS is provided as part of MPSL. 

As you have pointed out, it is possible to use MPSL FEM drivers without using the rest of MPSL. That's true and it should be possible for you to configure your application in such a way that the MPSL FEM APIs are available to his application.

Unfortunately, that only solves half of the problem. To take advantage of the MPSL FEM driver, it's not enough to have it available. It also needs to be used. The functions that configure the RADIO peripheral and handle the radio communication must call the MPSL APIs. That is what the SoftDevice Controller or 802.15.4 radio driver provided by Nordic do. That's also what radio test and DTM samples do. However, Zephyr BLE Controller does not do that. In its current shape Zephyr BLE Controller is not capable of using MPSL FEM driver.

Possible solutions

1. Switch to SoftDevice Controller. Then FEM is handled automatically and it's enough for you to provide appropriate devicetree overlays as explained in the documentation they linked. However, you indicated that's not an option for you.
2. Modify source code of the Zephyr BLE Controller. The code is open source so you can change it to incorporate calls to MPSL FEM APIs. That probably sounds like a lot of difficult work, so it's probably not an option either.
3. The Zephyr BLE Controller has support for PA/LNA: https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1-1/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio.c#L173-L180, https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1-1/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio.c#L182-L186 etc. From what I see it only supports front end modules compatible with two bindings: https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1-1/subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_nrf5_fem.h#L36-L44. One of them is the generic two control pin front end module: https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1-1/dts/bindings/net/wireless/generic-fem-two-ctrl-pins.yaml. It should be possible to define a node compatible with this binding in the network core's devicetree file and set its properties ( ctx-gpios , crx-gpios etc.) to match the customer's device. You can then also add an entry in the forwarder node in the application's core devicetree file that passes control over those pins to the network core. Example, just for reference: https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/thingy53_nrf5340/thingy53_nrf5340_common.dtsi#L113-L122.

The possible solutions discussed in number 3 point is based on self analysis, we are not sure how much feasible these are. You can try first and let us know the consequence.

Hope it will help.

Thanks.

BR

Kazi

[Jeff Gregorio]

I did some trial and error with the third solution. In my hci_rpmsg.overlay I added the FEM node at root level

/ {
	nrf_radio_fem: norab12_fem {
		compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
		ctx-gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
		crx-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
		tx-gain-db = <10>;
		rx-gain-db = <5>;
		ctx-settle-time-us = <1>;
		crx-settle-time-us = <1>;
 	};
};

I then added a pin forwarder node to my application core overlay:

/ {
	gpio_fwd: nrf-gpio-forwarder {
        compatible = "nordic,nrf-gpio-forwarder";
		status = "okay";
        norab12_fem-gpio-if {
            gpios = <&gpio1 8 0>, <&gpio1 9 0>;
        };
    };
};

Still no dice, so I ended up digging through the radio.c source and commenting out the first preprocessor check for HAL_RADIO_GPIO_HAVE_PA_PIN to see that it errored on the reference to FEM_NODE. Going to where that was defined showed that it was looking for DT_PHANDLE(DT_NODELABEL(radio), fem), so I added the missing node to hci_rpmsg.overlay

&radio {
	fem = <&nrf_radio_fem>;
};

And it works! 

Thank you very much for your help.

[PaKa]

Please note that the combination of technologies you are looking at now does not have a QDID and as far as I am aware of there won't be one made either.

The nRF Connect SDK 2.1 has a QDID for using the Zephyr controller together with the nRF52833 as a Direction Finding receiver and transmitter, newer versions don't have QDIDs so you will have to qualify the system on your own.

We do support Direction Finder transmitters with the nRF Connect SDK with the SoftDevice Controller subsystem (SDC), this gets updated QDIDs for each tag.

None of the qualified systems support using FEMs so usage of a FEM will again trigger a full qual cycle ffor you with the Bluetooth SIG.