Lines Matching full:sensor
13 Sensing Subsystem is a high level sensor framework inside the OS user
14 space service layer. It is a framework focused on sensor fusion, client
15 arbitration, sampling, timing, scheduling and sensor based power management.
17 Key concepts in Sensing Subsystem include physical sensor and virtual sensor objects,
18 and a scheduling framework over sensor object relationships.
19 Physical sensors do not depend on any other sensor objects for input, and
20 will directly interact with existing zephyr sensor device drivers.
21 Virtual sensors rely on other sensor objects (physical or virtual) as
24 The sensing subsystem relies on Zephyr sensor device APIs (existing version or update in future)
25 to leverage Zephyr's large library of sensor device drivers (100+).
28 devices can use the Zephyr :ref:`sensor` API directly.
31 kernel space and could support various customizations and sensor
32 algorithms in user space with virtual sensor concepts. The existing
33 sensor device driver can focus on low layer device side works, can keep
37 The sensing subsystem is decoupled with any sensor expose/transfer
39 Applications with different sensor expose/transfer protocols,
41 MQTT sensor Applications according different products requirements. Or even support multiple
42 Applications with different up-layer sensor protocols at the same time
46 cross host OSes support and as well as IoT sensor solutions.
58 * Based on Zephyr existing low-level Sensor API (reuse 100+ existing sensor device drivers)
60 * Separate option CHRE Sensor PAL Implementation module to support CHRE.
68 * Focus on framework for sensor fusion, multiple clients, arbitration, data sampling, timing
71 * Sensor Abstraction
72 * ``Physical sensor``: interacts with Zephyr sensor device drivers, focus on data collecting.
73 * ``Virtual sensor``: relies on other sensor(s), ``physical`` or ``virtual``, focus on
81 * single thread main loop for all sensor objects sampling and process.
95 ``Sensing Sensor API`` is for development ``sensors``.
101 * Sensor Configuration Flow
105 :alt: Sensor Configuration Flow (App set report interval to hinge angel sensor example).
107 * Sensor Data Flow
111 :alt: Sensor Data Flow (App receive hinge angel data through data event callback example).
113 Sensor Types And Instance
116 The ``Sensing Subsystem`` supports multiple instances of the same sensor type,
117 there're two methods for Applications to identify and open an unique sensor instance:
119 * Enumerate all sensor instances
121 :c:func:`sensing_get_sensors` returns all current board configuration supported sensor instances'
125 open specific sensor instance for future accessing, configuration and receive sensor data etc.
128 to dynamically enumerate the underlying platform's sensor instances.
130 * Open the sensor instance by devicetree node directly
132 Applications can use :c:func:`sensing_open_sensor_by_dt` to open a sensor instance directly with
133 sensor devicetree node identifier.
143 sensor(s).
146 ``Sensor type`` follows the
147 `HID standard sensor types definition <https://usb.org/sites/default/files/hutrr39b_0.pdf>`_.
151 Sensor Instance Handler
154 Clients using a :c:type:`sensing_sensor_handle_t` type handler to handle a opened sensor
155 instance, and all subsequent operations on this sensor instance need use this handler,
156 such as set configurations, read sensor sample data, etc.
158 For a sensor instance, could have two kinds of clients:
159 ``Application clients`` and ``Sensor clients``.
161 ``Application clients`` can use :c:func:`sensing_open_sensor` to open a sensor instance
164 For ``Sensor clients``, there is no open API for opening a reporter, because the client-report
165 relationship is built at the sensor's registration stage with devicetree.
167 The ``Sensing Subsystem`` will auto open and create ``handlers`` for client sensor
169 ``Sensor clients`` can get it's reporters' handlers via :c:func:`sensing_sensor_get_reporters`.
173 :alt: Sensor Reporting Topology.
177 generated by Sensing Subsystem according devicetree definitions, handlers between client sensor
179 Application(s) need to call :c:func:`sensing_open_sensor` to explicitly open the sensor instance.
181 Sensor Sample Value
186 Each sensor sample value defines as a common ``header`` + ``readings[]`` data structure, like
211 If a sensor has batched data where two consecutive readings differ by more than ``4295`` seconds,
215 This concept is referred from `CHRE Sensor API <https://github.com/zephyrproject-rtos/
220 ``Sensing Subsystem`` uses per sensor type defined data format structure,
230 :c:macro:`SENSING_SENSOR_TYPE_LIGHT_AMBIENTLIGHT` sensor,
233 :c:macro:`SENSING_SENSOR_TYPE_MOTION_HINGE_ANGLE` sensor
241 Sensing subsystem using device tree to configuration all sensor instances and their properties,