# Architecture If you’re familiar with the Qualcomm® sensing hub (QSH) terminology, architecture, and components, and intend to work with QSH APIs or set up sensor information, then see [Qualcomm® sensing hub APIs](https://docs.qualcomm.com/doc/80-80022-7/topic/qsh_api_reference.html#qsh-api-reference). Note Source code of the low-power application digital signal processor (aDSP), including the QSH framework, is available only to licensed users with authorized access. To upgrade your access, see [Working with Qualcomm](https://www.qualcomm.com/support/working-with-qualcomm). QSH is also known as Qualcomm® Snapdragon™ sensor core (SSC) that offers a unified event-driven framework for drivers and algorithms. QSH supports the same set of APIs for both the hardware-based and software-based sensors. Additionally, QSH supports asynchronous bus transfer and is extendable for new or custom driver features. QSH consists of the following components: > > > - QSH client APIs > - Sensor APIs > - Core framework > - Pre-implemented platform sensors > - Vendor-implemented sensors > - Test modules QSH serves external client applications and provides an interface to access sensor data. The following table describes the terms used in the QSH framework: Table : QSH terminology | **Term** | **Description** | | --- | --- | | Sensor |

Produces a single type of data, for example, accelerometer, gyroscope, timer, interrupt, and rotation vector.

Handles asynchronous data.

Publishes mandatory and custom attributes, and manages its instances.

| | Sensor instance |

Runs at a specific configuration, publishes output data events, and can be created per client request or shared among multiple requests.

Physical sensors usually share a single instance.

| | Sensor unique identifier (SUID) | A unique 128-bit ID for each sensor. | | Service | A module that provides a synchronous interface for common utilities. | | Data stream | A unique connection between a client and data source. | | Request | A configuration message that a client sends to a sensor (see `sns_request.h` file). | | Event | Asynchronous output data message that a sensor instance generates (see `sns_sensor_event.h` file). | | Nanopb | A small code-size protocol buffer implemented in ANSI C. | The following figure shows the QSH architecture: **Figure: QSH architecture** The QSH framework includes the following components: - Application processor software modules - Client application: It has the *application main()* or *entry function* that interacts with the QSH client APIs on the application processor side. - QSH client APIs: It offers high-level APIs to access services offered by QSH. It simplifies application development by abstracting system complexities and focusing on the application logic. For more information, see [Qualcomm® sensing hub APIs](https://docs.qualcomm.com/doc/80-80022-7/topic/qsh_api_reference.html#qsh-api-reference). - Low-power processor software modules - Client manager: The client manager is in charge of all communications of the low-power processor with the application processor. The following table describes key functionality of the client manager: Table : Client manager functions | Function | Description | | --- | --- | | Translate incoming requests | The client manager takes incoming requests and translates them into the nanopb protocol buffer format that the QSH can understand. For more information, see [Nanopb protocol buffer in QSH](https://docs.qualcomm.com/doc/80-80022-7/topic/nanopb_protocol_buffer_in_qsh.html#nanopb-protocol-buffer-in-qsh). | | Translate outgoing indications | The client manager receives event messages from the QSH and translates these event messages into outgoing indications in the nanopb protocol format that’s understandable outside the QSH. For more information, see [Nanopb protocol buffer in QSH](https://docs.qualcomm.com/doc/80-80022-7/topic/nanopb_protocol_buffer_in_qsh.html#nanopb-protocol-buffer-in-qsh). | | Guarantees batching options | If a client specifies certain batching (store/accumulate locally) options, the client manager ensures that they meet the batching options. The client manager checks that the data is grouped and sent in the same way that the client has specified, ensuring compliance with the criteria. | - Service manager: QSH offers synchronous services through service manager. The sensor and sensor instance use a callback to connect to the service manager. The `adsp_proc/qsh_platform/inc/sns_service.h` file lists the QSH services. The build process downloads the `adsp_proc` repository. For more information, see [Software build documentation](https://docs.qualcomm.com/doc/80-80022-254). The following table describes the key QSH services that are essential for device drivers. Table : QSH services | QSH service | Description | | --- | --- | | Stream service |

This service allows a sensor to create and remove a data stream.

For more information about the data stream to send requests and receive events over the data streams, see the adsp_proc/qsh_platform/inc/sns_data_stream.h file.

| | Attribute service |

This service allows a sensor to publish sensor attributes or capabilities.

All standard attribute IDs and expected value types are defined in the sns_std_sensor.proto file.

All attribute values must be in the nanopb-encoded format. For more information, see Nanopb protocol buffer in QSH.

For more information about the attribute service, see the adsp_proc/qsh_platform/inc/services/sns_attribute_service.h file.

| | Diagnostic service |

This service provides debug message and data log packet services, and defines standard log packet IDs.

For more information about the diagnostic service, see the adsp_proc/qsh_platform/inc/services/sns_diag_service.h file.

| | Event service |

This service allows a sensor to publish output events from the source sensor instances.

For more information about the event service, see the adsp_proc/qsh_platform/inc/services/sns_event_service.h file.

| | Power rail service |

This service helps the physical sensors to register and vote for turning the power rails On or Off.

For more information about the power rail service, see the adsp_proc/qsh_platform/inc/services/sns_pwr_rail_service.h file.

| | Synchronous COM port (SCP) service |

Available to the physical sensors to register or deregister the COM port and perform synchronous transfers over the COM port.

For more information about the SCP service, see the adsp_proc/qsh_platform/inc/services/sns_sync_com_port_service.h file.

| | General purpose IO (GPIO) service |

Available to the physical sensors to read or write the GPIO value.

Effectively abstracts a low-level CoreBSP layer for controlling the GPIOs.

For more information about the GPIO service, see the adsp_proc/qsh_platform/inc/services/sns_gpio_service.h file.

| | Island service |

Available to the physical sensors to request for exiting from the island mode.

When an application must access DDR or non-island resources that are available in normal mode, the application code can use the island service.

For more information about the island service, see the adsp_proc/qsh_platform/inc/services/sns_island_service.h file.

| | File system service |

Available to the physical sensors for the file service management.

The abstract file system is a part of an application processor stack and is available for local access from a low-power processor.

For more information about the file system service, see the adsp_proc/qsh_platform/inc/services/sns_file_service.h file.

| - Platform sensor: QSH provides certain built-in sensors for platform or hardware-specific abstraction that other sensors and sensor instances can use. The following table describes the platform sensors: Table : Platform sensors | Platform sensor | Description | | --- | --- | | Registry sensor |

The registry sensor in QSH provides an interface for sensors to access registry data from persistent memory. It allows sensors to create a data stream, send requests, receive data events, subscribe to updates, and remove unnecessary data streams.

For more information about the registry sensor, see Configure sensors.

For more information about the registry sensor API, see the adsp_proc/qsh_api/pb/sns_registry.proto file.

| | Timer sensor |

The timer sensor in the QSH has an interface to initiate periodic or one-shot timers. Sensors that require timers must create a data stream, send requests, and read delivered data events.

For more information about the timer sensor API, see the adsp_proc/qsh_platform/api/public_sns/sns_timer.proto file.

| | Interrupt sensor |

The interrupt sensor in the QSH has an interface to register interrupts. Sensors that require interrupts must create a data stream, send requests, and read delivered data events.

For more information about the interrupt sensor API, see the adsp_proc/qsh_platform/api/public_sns/sns_interrupt.proto file.

| | Asynchronous COM port (ASCP) sensor |

The ASCP sensor in the QSH has an interface for asynchronous read and write operations over a communication port.

Sensors that require this feature must create a data stream, send requests, and read delivered data events.

For more information about the ASCP sensor API, see the adsp_proc/qsh_platform/api/public_sns/sns_async_com_port.proto file.

Note

The ASCP sensor is typically used by physical sensor drivers to read large first-in-first-out (FIFO). | | SUID lookup sensor |

The SUID lookup sensor in the QSH provides an API to obtain the SUID of dependent sensors. Its own SUID is available using the sns_get_suid_lookup() function in the sns_sensor_util.h file.

For more information about the SUID lookup sensor API, see the adsp_proc/qsh_api/pb/sns_suid.proto file.

| | Test sensor |

The test sensor customizes and runs sensor-specific use cases.

The test sensor is available in the adsp_proc/qsh_platform/sensors/test directory.

| - QSH utilities: QSH provides several helper utilities for sensors and sensor instances. All the utilities are available in the `adsp_proc/qsh_platform/inc/utils` directory. The following table describes the key QSH utilities: Table : QSH utilities | QSH utility | Description | | --- | --- | | Nanopb encode/decode |

Provides common encode and decode helper functions for all the sensors. For example, encode and decode sns_request messages, encode and publish, and decode data events.

Asynchronous COM port nanopb utilities are available for physical sensor drivers.

| | Sensor utils |

Provides common functionalities for sensors, such as finding a sensor instance and getting the SUID of a SUID lookup sensor.

| | Attribute utils |

Provides helper functions that encode and publish a sensor attribute.

| | Memory utils |

Provides helper functions for efficient memory management and allocation.

| | Math utils |

Offers a collection of mathematical functions and operations, such as matrix, fast Fourier transform (FFT), and infinite impulse response (IIR) filter.

| | Printf utils |

Includes helper functions to format and print data.

| - OS abstraction (OSA) provides a unified interface to operating system services, abstracting platform-specific implementations. Table: OSA Utilities | OS abstraction (OSA) | Description | | --- | --- | | Thread management |

Provides abstractions for thread creation, deletion, and management

Includes thread synchronization primitives (mutexes, semaphores, condition variables)

Enables platform-independent multi-threaded sensor framework execution

| | Signal handling |

Abstracts OS signal registration and delivery mechanisms

Provides signal attributes configuration and signal mask management

Enables event-driven task scheduling in the sensor framework

| | Mutex and Synchronization |

Provides mutual exclusion primitives for critical sections

Abstracts platform-specific locking mechanisms

Ensures thread-safe access to shared resources

| - Platform abstraction layer (PAL) provides hardware and platform-specific abstractions for sensor drivers and framework components. Table: PAL Utilities | Platform abstraction layer (PAL) | Description | | --- | --- | | GPIO abstraction |

Provides platform-independent GPIO pin control

Abstracts GPIO configuration, read, and write operations

Enables sensor interrupt and control signal handling

| | I^2^C/SPI bus abstraction |

Abstracts communication bus operations (I²C, SPI)

Provides read/write operations with platform-specific implementations

Enables physical sensor communication across different platforms

| | Interrupt handling |

Abstracts interrupt registration and handling mechanisms

Provides interrupt enable/disable and priority management

Enables sensor interrupt-driven data acquisition

| | Clock and Power management |

Abstracts clock configuration and power domain management

Provides platform-specific clock gating and power state control

Enables efficient power management for sensor subsystems

| | Register access |

Provides abstracted register read/write operations

Abstracts memory-mapped I/O and register access patterns

Enables hardware control across different SoC implementations

| | UART/Serial communication |

Abstracts serial port operations for debug and data logging

Provides platform-independent serial communication

Enables asynchronous COM port operations for sensor drivers

| ## Sensors and sensor instances QSH divides the sensor implementation in two logical units: sensor and sensor instance. - Sensors are producers, consumers, or a combination of producers and consumers of asynchronous data. - Each sensor can have one or more sensor instances. - Any request to a sensor for data results in the creation of a sensor instance or sharing of an existing sensor instance. - The sensor creates sensor instances on demand. - Sensors manage the lifecycle and configuration of their corresponding instances, and send configuration updates and initial state events to their clients. - Each sensor instance operates with a specific client configuration. - The sensor instance of a physical sensor programs the sensor hardware to operate at required configuration. - Vendors must serve all client requests with a minimal number of sensor instances. - The sensor instance generates and sends a stream of data to all the active clients. - Many sensors can share and configure a single sensor instance. This mode of operation is typical to a combo driver for hardware sensors, such as the following: - Accelerometer and gyroscope - Proximity and ambient light **Next steps** > > > [Messages](https://docs.qualcomm.com/doc/80-80022-7/topic/data_model.html#data-model) Last Published: May 07, 2026 [Previous Topic Overview](https://docs.qualcomm.com/bundle/publicresource/80-80022-7/topics/overview.md) [Next Topic Messages](https://docs.qualcomm.com/bundle/publicresource/80-80022-7/topics/data_model.md)