CAF: Sensor manager

The sensor manager sample demonstrates the functionality of the CAF: Sensor manager module. It uses the Simulated sensor 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	Build target
nRF5340 DK	PCA10095	nrf5340dk_nrf5340	nrf5340dk_nrf5340_cpuapp
nRF52840 DK	PCA10056	nrf52840dk_nrf52840	nrf52840dk_nrf52840

Overview

The sample provides simulated input data using Simulated sensor driver. The input data simulates acceleration in X, Y, and Z axes, with the acceleration generated as value of a periodic wave signal. 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.

Sensor stub

By default, the sensor manager sample uses Simulated sensor driver for sensor data simulation. You can select the sensor stub module instead. The sensor stub module has a simple implementation that relates fully to the application implementing the function to generate the sensor data. This sample implements a simple generator for the sensor stub that uses no floating point mathematics.

For more details on the sensor stub configuration, see the Sensor stub configuration section.

Configuration

See Configuring your application for information about how to permanently or temporarily change the configuration.

Single core configuration

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

To use this configuration, specify the -DOVERLAY_CONFIG=boards/<board>_singlecore.conf parameter along with the build command when building the sample:

west build -b nrf5340dk_nrf5340_cpuapp -- -DOVERLAY_CONFIG=boards/nrf5340dk_nrf5340_cpuapp_nrf5340_singlecore.conf

Sensor stub configuration

The Sensor stub configuration is provided in the sensor_stub_overlay.conf file. To use this configuration, specify the -DOVERLAY_CONFIG=sensor_stub_overlay.conf parameter along with the build command when building the sample.

For the multicore configuration, it would change to -Dremote_OVERLAY_CONFIG=sensor_stub_overlay.conf as shown in the following example:

west build -b nrf5340dk_nrf5340_cpuapp -- -Dremote_OVERLAY_CONFIG=sensor_stub_overlay.conf

When single-core configuration is used on multicore MCU, add the sensor selection after the single-core configuration parameter as shown in the following example:

west build -b nrf5340dk_nrf5340_cpuapp -- -DOVERLAY_CONFIG="boards/nrf5340dk_nrf5340_cpuapp_nrf5340_singlecore.conf;sensor_stub_overlay.conf"

Building and running

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

See Building and programming an application for information about how to build and program the application and Testing and debugging an application for general information about testing and debugging in the nRF Connect SDK.

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, PuTTY). See How to connect with PuTTY for the required settings.

2. Reset the kit.

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

   [00:12:* Booting Zephyr OS build v2.7.99-ncs1-2182-gbb39dfe3121a  *
   [00:00:00.258,605] <inf> event_manager: e:module_state_event module:main state:READY
   [00:00:00.258,728] <inf> event_manager: e:module_state_event module:sensor_sim_ctrl state:READY
   [00:00:00.258,850] <inf> event_manager: e:sensor_state_event sensor:accel_sim_xyz state:ACTIVE
   [00:00:00.258,941] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz
   [00:00:00.259,033] <inf> event_manager: e: sensor_data_aggregator_release_buffer_event
   [00:00:00.259,124] <inf> event_manager: e:module_state_event module:sensor_manager state:READY
   [00:00:00.458,526] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz
   [00:00:00.458,709] <inf> event_manager: e: sensor_data_aggregator_release_buffer_event
   [00:00:00.658,538] <inf> event_manager: e:sensor_data_aggregator_event Send sensor buffer desc: accel_sim_xyz
   [00:00:00.658,721] <inf> 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

• Wave generator

• Application Event Manager

• Event Manager Proxy

This sample uses the following nRF Connect SDK drivers:

• Simulated sensor driver

In addition, it uses the following Zephyr subsystems:

• include/ipc/ipc_service.h

• Logging