Common Application Framework and custom Sensor with Sensor Manager Module

[FinnBiggs]

Hi folks,

I'm trying to build an application with the CAF, and I'd like to use the sensor manager module, but I've run into a few problems -- any help would be appreciated.

I'll start with my environment and hardware setup, then I'll share the areas I'm getting stuck, plus a few key snippets of code. I'm happy to provide more information in a followup.

===== Environment =====

• Windows 11 Machine (MINGW bash terminal)
• VSCode 1.86 + NRF Connect for VSCode v2023.11.301
• Toolchain and SDK for nrfConnect v2.5.0

===== Hardware =====

• Xiao BLE Sense (nRF52840)
• LSM6DS3-TR-C IMU (built-in) (compatible with lsm6dsl example)

===== Description of steps =====

I'm trying to modify the caf_sensor_manager example (nrf/samples/caf_sensor_manager), which uses both the sensor aggregator and sensor manager modules to run the imu on my xiao board.

The initial example runs perfectly well on both my test environment (nrf52840dk) and on the xiao ble sense (with the sensor_stub and agg added into the dts overlay).

I disabled the sensor aggregator in KConfig, and wrote a new module ("sensor_print.c") that subscribes to sensor_event. This also works as expected, and I can access the sensor data and print it to the console from that module.

Next, I wanted to add the LSM6DS3 to the example, so I started following the procedure listed here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/caf/sensor_manager.html#configuration

1. Physically connect the sensor (done, sensor is embedded)
2. Add and enable sensor in the device tree file.
   

   1. /* SNIPPET FROM xiao_ble_sense.dts */
      &i2c0 {
      	compatible = "nordic,nrf-twim";
      	/* Cannot be used together with spi0. */
      	status = "okay";
      	pinctrl-0 = <&i2c0_default>;
      	pinctrl-1 = <&i2c0_sleep>;
      	pinctrl-names = "default", "sleep";
      	clock-frequency = <I2C_BITRATE_FAST>;
      
      	lsm6ds3tr_c: lsm6ds3tr-c@6a {
      		compatible = "st,lsm6dsl";
      		reg = <0x6a>;
      		irq-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
      		status = "okay";
      	};
      };

   2. As far as I can tell from reading the docs, ADDING means including the node in the dts and ENABLING means including a status="okay" entry in that node
3. Enable the CONFIG_CAF_SENSOR_MANAGER and CONFIG_SENSOR KConfig options
   1. These options are enabled in my xiao_ble_sense.conf KConfig overlay, which is included in my build
4. Enable the sensor of your choice in KConfig.
   1. Here is where I run into trouble

===== The Trouble =====

When I open the KConfig GUI for step 4, I encounter the following

The chip is disabled, and the option is greyed out. Trying to determine why, I observe the following

It seems that KConfig is telling me that DT does NOT have the ST_LSM6DSL enabled.

When I try to follow that to its definition, I observe the following.

The option which is failing is DT_HAS_ST_LSM6DSL_ENABLED

This led me to investigate whether my device tree has the LSM6DSL enabled.

my xiao_ble_sense.dts has:

&i2c0 {

    compatible = "nordic,nrf-twim";

    /* Cannot be used together with spi0. */

    status = "okay";

    pinctrl-0 = <&i2c0_default>;

    pinctrl-1 = <&i2c0_sleep>;

    pinctrl-names = "default", "sleep";

    clock-frequency = <I2C_BITRATE_FAST>;

    lsm6ds3tr_c: lsm6ds3tr-c@6a {

        compatible = "st,lsm6dsl";

        reg = <0x6a>;

        irq-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;

        status = "okay";

    };

};

Notably, a node for lsm6ds3tr_c with compatible st,lsm6dsl, and status "okay".

Something is incorrect here, or I should be able to enable the KConfig lsm6dsl options, but I can't find what it is for the life of me.

===== Behavior Post-Problem =====

Despite this, I can configure the sensor in the manner suggested by step 5 of the device manager docs.

I configure the channels and sample rate for my device and can build and flash the code with no trouble.

When the code runs, I get only 0's off the sensor. (though the sensor_state_event reports the device as having status "ready" when checked).

===== Past Success with this sensor =====

I have standalone code for operating the LSM6DSL, and I've adapted that code to also work with the application event manager (a global trigger thread in a dedicated module submits an "imu_event")

I'd like to use the prebuilt CAF modules to run this sensor, but can't at present.

===== Questions =====

1. What am I doing wrong that I cannot enable the LSM6DSL in KConfig?
2. What are my next steps for implementing this?

Thank you so much for any help you can provide.

Best,

    - Finn

[FinnBiggs]

Hi again folks

More confusion on my end.

grepping for the option being counted as "n" (DT_HAS_ST_LSM6DSL_ENABLED) reveals the following:

in the build for xiao, DT_HAS_ST_LSM6DSL_ENABLED is set to "Y",

and checking that file info, in build_xiao/zephyr/.config, I see the following:

But the KConfig option is still disabled.

What should I do to enable my sensor?

===== Edits =====

Which, come to think of it, if this is enabled in the zephyr build, the KConfig option should be enabled by default.

If that's not the problem, what is?

Thanks again

    - Finn

[Elfving]

Hi Finn, and sorry about the wait. Things are busy here on DevZone these days.

Just letting you know that I am looking into it.

I'm glad that you have a sample with the LSM6DS3 running though. The issue is typically to find the one thing lacking in the dts or in KConfig, now you can atleast compare etc.

Regards,

Elfving

[Elfving]

Hello Finn, I am deeply sorry about the delay on this case. I've been overlooking this for quite a while now.

Has there been any development on this from your side?

Regards,

Elfving

[FinnBiggs]

Hello Elfving,

No worries, I opted to move on to a different system for managing my sensor. I've configured the LSM6DSL as a non-CAF device and am using the provided drivers to run it as a globally triggered thread, which makes use of the IRQ pin to trigger my sensor at the frequency I need it to run.

If you have insight as to how I might use CAF sensor drivers to set my device to 104Hz, (or other useful configuration settings such as i2c control), I would be very interested and appreciative. If not, I think it would be reasonable to close this question.

As an aside, for folks in a similar situation:

I'd recommend the the lsm6dsl sample (zephyr/samples/sensor/lsm6dsl/ ) and then use the global trigger thread (CONFIG_LSM6DSL_TRIGGER_GLOBAL_THREAD=y) to feed events to the App Event Manager, then go from there with your application.

My current challenge is implementing additional functionalities using direct i2c and that discussion is here:  LSM6DSL Driver Limitations - advice to expand functionality. 

I'd be quite grateful if you have insight on that front Elfving

Best regards,

    - Finn

[Elfving]

FinnBiggs said:

If you have insight as to how I might use CAF sensor drivers to set my device to 104Hz

I had a talk with one of the developers who's been using CAF for the nRF Desktop, and I believe you are right. The sampling period is defined in ms, so you can get some reasonable sampling frequency, but not 104Hz exactly. 

I can put in a request for CAF to support a higher accuracy if that is something you'd be interested in. What accuracy would you need for this sensor? If we, lets say, let you set a polling interval in µs instead of ms to get a better accuracy, would that work for you? Allowing you to set a certain polling frequency in hertz and try to do some calculations to avoid possible drift might be best.

As you are not using CAF at the moment though I assume this request isn't a big priority for you?

Regards,

Elfving

[FinnBiggs]

Hi Elfving,

Thank you for checking on this. For me to be able to use CAF, it would really need to handle an assigned sensor frequency and/or make use of the interrupt pin to submit a sensor event. Now that I'm a little more immersed in this ecosystem, it looks like CAF sensor is best for very simple devices (e.g. thermocouple) that don't have interrupt systems.

The higher accuracy (uS) may be useful for some folks, but it doesn't cover my development plan later-on. (I'll be swapping the configured functionality of my sensor via i2c to detect different kinds of input e.g. tap, freefall).

Yes, though -- I am not using CAF, so this is lowest-priority.

Best,

    - Finn

[Elfving]

Understood.

FinnBiggs said:

Now that I'm a little more immersed in this ecosystem, it looks like CAF sensor is best for very simple devices (e.g. thermocouple) that don't have interrupt systems.

I'm no CAF expert, but my understanding is the opposite, that you would typically use CAF for more complex applications. Eg. the Asset Tracker. 

I've made a request for this, although with a low priority. Let me know if there is anything else, or if you want me to up the priority on this.

Regards,

Elfving