> ## Documentation Index
> Fetch the complete documentation index at: https://dragonwingdocs.qualcomm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Qualcomm® sensing hub APIs

The Qualcomm® sensing hub (QSH) interfaces are available for hardware-based, software-based, pre-existing, or any other QSH-compliant sensors. The QSH framework runs on low-power processors and exposes the APIs at the application processor. These APIs include the following:

* QSH client APIs and various feature APIs for application development.
* Sensor APIs to create new sensors on a low-power processor.

## Application processor APIs

QSH offers feature APIs on the application processor to address specific sensor use cases.

***

### QSH client APIs

The QSH client APIs provide an interface that enables client code to access the QSH functionality and develop end-to-end sensor applications. The QSH supports the following APIs:

***

#### `getSession()`

This API creates an instance of `ISession` and returns a pointer to it.

**Syntax**

```cpp theme={null}
ISession* getSession();
```

**Parameters** — None.

**Response**

| Return      | Description                                        |
| ----------- | -------------------------------------------------- |
| `ISession*` | `ISession`: Upon success; `nullptr`: Upon failure. |

***

#### `open()`

This API initiates the client session created using `getSession()` API. The `Open()` API sets up and establishes communication between the client and the QSH framework. The client must call this function only once per session.

**Syntax**

```cpp theme={null}
int open();
```

**Parameters** — None.

**Response**

| Return | Description                                           |
| ------ | ----------------------------------------------------- |
| `int`  | `0`: Successfully opened session; `-1`: Upon failure. |

***

#### `setCallBacks()`

For a specified SUID, this API allows the user to set callbacks for responses, errors, and events received over the session opened using `Open()` API. This API registers the SUID with the callback functions passed as parameters to this API.

To unset the callbacks for already registered SUID, you can pass `nullptr` for all the three callback functions: `respCallBack`, `errorCallBack`, and `eventCallBack`. Passing `nullptr` for all callback functions results in an error for an unregistered SUID.

**Syntax**

```cpp theme={null}
virtual int setCallBacks(suid suid, respCallBack respCB, errorCallBack errorCB, eventCallBack eventCB) = 0;
```

**Parameters**

| Parameter | Name      | Description                                                      |
| --------- | --------- | ---------------------------------------------------------------- |
| `input`   | `suid`    | Unique SUID of the sensor for which the callbacks are being set. |
| `input`   | `respCB`  | Response callback function.                                      |
| `input`   | `errorCB` | Error callback function.                                         |
| `input`   | `eventCB` | Event callback function.                                         |

**Response**

| Return | Description                                                                                                   |
| ------ | ------------------------------------------------------------------------------------------------------------- |
| `int`  | `0`: Upon success; `-1`: Upon failure, if all the callback functions are `nullptr`, for an unregistered SUID. |

***

#### `sendRequest()`

This API asynchronously sends a protocol buffer (proto) encoded message to the QSH framework. The proto-encoded message has instructions or configuration settings for the sensor identified by the SUID.

For a specified SUID, if you set the callback pointers using `setCallBacks()` API, then the response, event, or a combination of responses and events are received from the QSH framework.

**Syntax**

```cpp theme={null}
virtual int sendRequest(suid suid, string message) = 0;
```

**Parameters**

| Parameter | Name      | Description                                            |
| --------- | --------- | ------------------------------------------------------ |
| `input`   | `suid`    | A unique SUID of the sensor for request is to be sent. |
| `input`   | `message` | Proto-encoded request message to be sent.              |

**Response**

| Return | Description                                                                                                                                                                                                                        |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `int`  | `0`: Upon success; `-1`: Upon failure, due to one of the following: user tries to send a request over a closed session; encoded message size exceeds the permissible size; sending message fails due to the channel related issue. |

***

#### `close()`

This API closes the sensor session and terminates the communication between the client and the QSH framework. The client must call this function at the end of the session to release the resources and avoid memory leaks.

**Syntax**

```cpp theme={null}
void close();
```

**Parameters** — None.

**Response**

| Return | Description |
| ------ | ----------- |
| `void` | None.       |

***

For more information and example codes, see [Develop applications using the QSH client APIs](./develop_app).

### QSH direct channel APIs

QSH direct channel APIs provides low latency sensor data channel for high rate applications. Direct channel APIs use the FastRPC interface, which bypasses the standard interprocessor communication (IPC) mechanism to achieve faster communication. For more information, see [Qualcomm sensing hub APIs](https://docs.qualcomm.com/doc/80-80023-7A/topic/overview.html#qualcomm-sensing-hub-apis).

## Low-power processor APIs

The low-power processor APIs provide access to the following:

* QSH framework resources, such as services and utilities.
* Core functionalities, such as the diagnostic interface and timer.

You can use the low-power processor APIs to create algorithms and sensor drivers that comply with the QSH standards. For more information, see [Qualcomm sensing hub APIs](https://docs.qualcomm.com/doc/80-80023-7A/topic/overview.html#qualcomm-sensing-hub-apis).

**Next steps**

* [Software for application and low-power processors](./software)