Skyworks FEM control with 802.15.4 with NCS/Zephyr 2.0.0

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

  • Unfortunately my code is set up for a custom board and full of customer IP so I don't have a nice package I could send you.

    I suggest you try the trick to edit the .dts to tell it the CTX and CRX pins are on different GPIO that you have access to. If you can put an oscilloscope or logic analyzer on them you'll be able to see if the module is toggling those pins when it's time to transmit (obviously your RSSI *really* won't be good since the FEM definitely won't be getting turned on and off in this state).

    If they are toggling you're almost there - just make sure you're setting CPS low and CHL high (I'm using 

    gpio_pin_configure for those) and make sure you're setting the output power level correctly - also maybe experiment with different power levels from -40 to as high as it will go to see what your RSSI does.  I found my signal stopped getting better after +22 or maybe +24.
    If they aren't toggling, it's probably something related to the configuration. Try looking in the autoconf.h file in the build directory to see what's getting included in the final build. Here's what the CONFIG_MPSL section of mine looks like (I've just got CONFIG_MPSL and CONFIG_MPSL_FEM in my prj.conf, and that stuff in my kconfig pulls in the GENERIC_TWO_CTRL_PINS thing):
    #define CONFIG_MPSL_FEM_GENERIC_TWO_CTRL_PINS_SUPPORT 1
    #define CONFIG_MPSL_FEM 1
    #define CONFIG_MPSL_FEM_SIMPLE_GPIO 1
    #define CONFIG_MPSL_FEM_DEVICE_CONFIG_254 1
    #define CONFIG_MPSL_THREAD_COOP_PRIO 8
    #define CONFIG_MPSL_WORK_STACK_SIZE 1024
    #define CONFIG_MPSL_TIMESLOT_SESSION_COUNT 0
    Good luck,
    Glen
  • Thank you for the info and suggestions. Yes, I was going to try and look at CTX/CRX to see if they're being toggled correctly (autoconfig.h looks good).
    May I ask what version of the SDK you're using? I'm using v2.2.0

  • Actually, it started working for me after I set 

    tx-gain-db = < 2 >; (instead of 22)

    Thanks for all your help!

  • Interesting - I wonder if that's a difference in the nCS version (since I used 2.0.0 and you're at 2.2.0) or if it's because you're setting it in the dts file instead of through a function call. I really miss the days of thorough software documentation where there would be a section describing everything about how each module works instead of the Doxygen self-documenting junk everyone pretends is documentation now.

  • There's definitely something different between 2.0.0 and 2.2.0.

    I've started with a custom implementation for the Skyworks FEM of the BT840X because I was using Zephyr OS "vanilla" and the implementation was only for bluetooth there (maybe I'm wrong). A few days ago, I've switched to nRF Connect SDK 2.0.0 as I was on Zephyr OS 3.0.0 previously. Everything was working great. Then I've switched to nRF Connect SDK 2.2.0 to be up-to-date but the TX power dropped by a lot (~20dBm). I was unable to make it work at the previous TX power levels I was on 2.0.0.

    I still don't know why and where this difference comes from but I've switched back to 2.0.0.

Related