Skip to main content
The SessionClient sample application shows the usage of QSH client API to develop applications. By default, this sample application is built in the /usr/bin directory on the device. For a complete code sample, see the <workspace>/build-qcom-wayland/workspace/sources/sensinghub/sensing-hub/examples/SessionClient/SessionClient.cpp file. The following figure shows the call flow for streaming the accelerometer sensor and the usage of the QSH client APIs.
Figure : Call flow to stream a specified sensor

Figure: Call flow to stream a specified sensor

In this example, the client application can use different sensor sessions for the SUID query, attribute query, and streaming activity. It can also use the same session for all the activities; however, synchronization must be handled appropriately. The client application can send various requests to the aDSP as follows:
  1. The SUID query, retrieves SUIDs for the specified sensor: a. Create an interface for SUID by calling the getSession() API with the new sessionFactory() class. Requesting the SUID is the first and important request to get SUID of the requested data type for any use case.
    b. Open a created session interface by calling the open() API.
    c. Set callbacks by calling the setCallBacks() API and handling the response, event, or error for the SUID activity.
    d. Create and send a Pb-encoded request message for SUID of a specified data type by calling the sendRequest() API.
    e. Close the session by calling the close() API and delete it after receiving the SUID events for the requested data type.
  2. The attribute request, retrieves attributes for the specified sensor: a. Create an interface session for an attribute by calling getSession() with the new sessionFactory() class. Requesting the attributes is important to get the capabilities of the requested data type for any use case.
    b. Open a created session interface by calling the open() API.
    c. Set callbacks by calling setCallBacks() and handling the response, event, or error for the attribute activity.
    d. Create and send a Pb-encoded configuration request for an attribute of a specified data type by calling the sendRequest() API.
    e. Close the session by calling the close() API after receiving the attribute events for the requested data type.
  3. The sensor streaming, streams the sensor and receives the data events: a. Create an interface session for streaming the sensor by calling getSession() with the new sessionFactory() class. Here, requesting sensor data is the final stage of a requested data type for any use case.
    b. Open a created session interface by calling the open() API.
    c. Set callbacks by calling setCallBacks() and handling the response, event, or error for streaming the activity.
    d. Create and send a Pb-encoded configuration request for streaming the sensor of a specified data type by calling the sendRequest() API, which eventually allows the requested sensor.
    e. Handle samples in the event callbacks and wait for the specified duration of the test.
  4. The stop sensor streaming client, stops streaming by sending a request to disable: a. Call the sendRequest() API.
    b. Close the session by calling the close() API after receiving the streaming events for the requested data type.
The following snippet shows the SessionClient sample application output. It allows an accelerometer sensor with 10 Hz sample rate and a 2-second batch period for 10 sec and prints the received sensor events.
For troubleshooting common issues, see Debug. For more information, see QSH direct channel API workflow.