Skyworks FEM control with 802.15.4 with NCS/Zephyr 2.0.0

[Glen M]

Hi,

I'm having trouble getting the FEM in my Fanstel BT840X module working (the module with the nRF52840 processor and Skyworks 66112 amplifier).

I'm using nRF Connect version 2.0.0, though I can upgrade if it helps.

The first issue I've had is conflicting documentation on how to do this. I found that the recommended path of adding CONFIG_MPSL and CONFIG_MPSL_FEM does not build if you have CONFIG_NRF_802154_SOURCE_HAL_NORDIC in the project. I started this project from radio_test originally, and that sample uses the _NORDIC version.

The radio_test sample puts references to fem.c and generic_fem.c from the /nrf/samples/bluetooth/direct_test_mode/src/fem/ directory into CMakeLists.txt and Kconfig and it seems to expect you to use CONFIG_FEM and CONFIG_GENERIC_FEM in prj.conf. That scheme will at least build along with CONFIG_NRF_802154_SOURCE_HAL_NORDIC so I've been trying to use that.

Based on other support tickets I found, and information at this link,: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.0/nrf/ug_radio_fem.html#ug-radio-fem-skyworks

I modified my .dts file to add this code in the / { section:

nrf_radio_fem: skyworks_fem {
compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
ctx-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
crx-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
cps-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
chl-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
};

and this code outside of that section: 

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

For my testing, I turned down the transmit power to -20dBm, and with the amplifier off my two boards can see each other at about -59dBm across my desk. At this level my boards can communicate but I'd definitely see a jump in RSSI if the amplifier were working.

If I put in the modified .dts file, my two devices can no longer talk to each other - regardless of the presence or absence of any CONFIG values in the prj.conf. So it seems like the .dts changes are making a difference, but not in the direction I expected.

Please help! This is urgent!

Thanks,

Glen

[Jørgen Holmefjord]

Hi,

Can you try setting cps-gpios to GPIO_ACTIVE_LOW? According to the SKY66112-11 datasheet, setting CPS high will put the FEM in "Receive/Transmit bypass mode", which will give you approximately -2 dB gain.

Best regards,
Jørgen

[Glen M]

Didn't seem to make any difference. I decided to take the CPS and CHL out of the devicetree file and just configure them directly in firmware since they don't change anyway. So I'm just configuring the GPIO for CPS to always be 0 and for CHL to always be 1.

I'm trying to dig into the generic FEM code to understand how it works.

Is there a way to get an interrupt/callback function to fire just before and after any transmits (including 802.15.4 acknowledgements) where I could just manually control the pins and not have to fight with all this nonsense?

Thanks,

Glen

[Glen M]

I just had a thought - maybe the devicetree stuff is working fine and the reason I'm not seeing packets through is that I'm not initializing or using the generic FEM driver code correctly. Am I supposed to call some functions in my code to set up/use that driver?

My code is using nrf_802154_transmit_raw() to send packets and nrf_802154_transmitted_raw() and nrf_802154_transmit_failed() to know when the attempt to send it is complete.

I'm assuming that somewhere along the way, nrf_802154_transmit_raw somehow calls the FEM code to switch the GPIO to TX mode, then off to listen for the 802.15.4 ack as soon as it's been sent. is that how this works and will the driver I'm trying to use do what I want?

To receive packets I defined my own instance of rf_process_rx_packets where I call my own little ISR function to save off the info etc and then nrf_802154_buffer_free_raw.

[Jørgen Holmefjord]

As described in Supporting Front-End Modules: "The driver supports Front-End Modules (FEMs) using an implementation provided by the Multiprotocol Service Layer."

Did you manage to enable MPSL in your application? If not, the FEM functionality will likely not work. The radio test sample have its own FEM implementation (shared with the DTM sample), as it interfaces directly with the RADIO peripheral, not through MPSL.

[Glen M]

Hi Jørgen,

I've been working on the MPSL stuff today - I removed CONFIG_NRF_802154_SOURCE_HAL_NORDIC=y and I added the following configs (not sure if all of them are necessary):

CONFIG_MPSL=y

CONFIG_MPSL_FEM=y

CONFIG_MPSL_FEM_SIMPLE_GPIO=y

CONFIG_MPSL_FEM_DEVICE_CONFIG_254=y

As I mentioned above, I'm manually controlling the CPS and CHL lines, so all I have added to the dts file at this point is this: 

/{ nrf_radio_fem: skyworks_fem {
compatible = "skyworks,sky66112-11", "generic-fem-two-ctrl-pins";
ctx-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
crx-gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
};
};

I've found that with those .dts changes, the signal level is lower than it is without. So "turning on" the amplifier is apparently making things worse.

I stumbled on some documentation for the MPSL code and related files here: /nRF_Connect/v2.0.0/nrfxlib/mpsl/doc/fem.rst

/nRF_Connect/v2.0.0/nrfxlib/mpsl/doc/pic/FEM_sequence_simple.svg

/nRF_Connect/v2.0.0/nrfxlib/mpsl/include/protocol/mpsl_fem_protocol_api.h

From looking at those files, it looks like I'm supposed to figure out the exact timing of my radio exchange and feed the MPSL library a timer and the compare/capture timings where I want all the  RX/TX switching to occur. Am I interpreting that correctly? I'd imagined that the driver would take care of all of that for me and I'll I'd have to do to use the FEM code would be to get the .dts and .conf information correct.

 

If I do need to manually configure the driver to carry out its operations, is there any example code or assistance for figuring all of that out for 802.15.4? I searched devzone for the mpsl_fem_pa_configuration_set function and apparently nobody has ever asked about that before.

 

Thanks

Glen