CAF: Sensor manager

The sensor manager sample demonstrates the functionality of the CAF: Sensor manager module. It uses the Sensor stub driver, the sensor manager module, the CAF: Sensor data aggregator module, and the workload simulator module to automatically sample and gather data and then receive and process it in packages.

Requirements

The sample supports the following development kits:

Hardware platforms	PCA	Board name	Board target
nRF54H20 DK	PCA10175	nrf54h20dk	nrf54h20dk/nrf54h20/cpuapp
nRF5340 DK	PCA10095	nrf5340dk	nrf5340dk/nrf5340/cpuapp
nRF52840 DK	PCA10056	nrf52840dk	nrf52840dk/nrf52840

Overview

The sample provides stub input data using Sensor stub driver. The input data simulates acceleration in X, Y, and Z axes. Whenever new data is generated, the CAF: Sensor manager module generates the appropriate sensor_event instances that include the generated data.

The data from the events is then passed to the CAF: Sensor data aggregator module. When the aggregator’s buffer is full, the application sends aggregated data to the workload simulator module (workload_sim). The workload simulator is a custom module used by this sample only. This module handles the data received from the CAF: Sensor data aggregator module, simulates workload on data using k_busy_wait() and notifies the aggregator module when the aggregator buffer can be freed.

If you are running this sample on an SoC with multiple cores, the workload simulator module (workload_sim) is placed on the second core. All communication between the cores is done using Event Manager Proxy and Zephyr subsystem include/ipc/ipc_service.h.

Configuration

See Configuring and building for information about how to permanently or temporarily change the configuration.

Single-core configuration

For the MCU with multiple cores, the default configuration uses one core to simulate the sensor and the other core to process the sensor. The multicore MCUs can also support a single-core configuration, where the sensor is simulated and processed on a single, selected core. The configuration is placed in the boards/<board>_singlecore.conf file.

To use this configuration, run the following command:

west build -b nrf5340dk/nrf5340/cpuapp -- -DFILE_SUFFIX=singlecore

Building and running

For the MCU with multiple cores, the default configuration ensures that all the required cores are built. You can build and flash all the required images by completing the following steps for all the required cores.

This sample can be found under samples/caf_sensor_manager in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

Complete the following steps to program the sample:

1. Go to the sample directory.

2. Start the toolchain environment in a terminal window.

3. Run the following command to build the application code for the host and the remote:

   west build -b nrf5340dk/nrf5340/cpuapp
   

4. Program both the cores:

   west flash
   

Note

Programming the nRF54H20 SoC can sometimes fail due to conflicts in the resource configuration. This can happen if, for example, an application programmed to the nRF54H20 SoC configured the UICRs for one or more cores in a way that is incompatible with the configuration required by the application you are trying to program on the SoC.

To fix this error and erase the UICR for the application core, run the following command:

nrfutil device recover --core Application

If your sample also uses the radio core, you must also erase the UICRs for the radio core. To erase the UICR for the radio core, run the following command:

nrfutil device recover --core Network

For more information on the command, run:

nrfutil device recover --help

You can then run west flash to program your application.

Testing

After programming the sample to your development kit, test it by performing the following steps:

1. Connect to the kit with a terminal emulator (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.

2. Reset the kit.

3. Observe that output similar to the following is logged on UART:

   * Booting Zephyr OS build v3.0.99-ncs1-2759-g07737b0b09e7  *
   [00:00:00.257,232] <inf> main: Event manager initialized
   [00:00:00.258,239] <inf> event_proxy_init: Event proxy remote added
   [00:00:00.259,948] <inf> event_proxy_init: Event proxy sensor_data_aggregator_event registered
   [00:00:00.260,009] <inf> event_proxy_init: Event manager proxy started
   [00:00:00.260,284] <inf> event_proxy_init: All remotes ready
   [00:00:00.260,345] <inf> app_event_manager: e:module_state_event module:main state:READY
   [00:00:00.260,742] <inf> app_event_manager: e:sensor_data_aggregator_event Send sensor buffer desc address: 0x100e28a
   [00:00:00.260,894] <inf> app_event_manager: e: sensor_data_aggregator_release_buffer_event
   [00:00:02.260,620] <inf> app_event_manager: e:sensor_data_aggregator_event Send sensor buffer desc address: 0x100e28a
   [00:00:02.260,864] <inf> app_event_manager: e: sensor_data_aggregator_release_buffer_event

Dependencies

This sample uses the following nRF Connect SDK libraries:

• CAF: Sensor manager module

• CAF: Sensor data aggregator module

• Application Event Manager

• Event Manager Proxy

This sample uses the following nRF Connect SDK drivers:

• Sensor stub driver

In addition, it uses the following Zephyr subsystems:

• include/ipc/ipc_service.h

• Logging