# Sensor testing tools Use the following tools to perform functional testing, set up the build environment, and functional diagnosis. ## Sensor functional test tools The test tools ensure the accuracy, reliability, and optimal performance of both the hardware-based and software-based sensors in your applications. The following tools facilitate comprehensive testing of the sensor functionalities. - The sensor info test provides detailed information about the sensor. - The driver acceptance test ensures that the sensor drivers are functioning correctly and are compatible with Qualcomm sensing hub (QSH). - The sensor workhorse is a tool to stress-test the sensors under various conditions. ### Use sensor info test to list supported sensors The sensor info test `ssc_sensor_info` is an application within the QSH test suite. It lists the QSH supported sensors and their attributes. You can run the following query at high-level operating system (HLOS) to get the attributes of a specified data type. > > > ssc_sensor_info [-sensor=] [-delay=][-duration=][-default_only=<1|0>][-log=<1|0>][-help] > Copy to clipboard The following table describes the parameters used by the `ssc_sensor_info` test application. Table : Parameters of ssc_sensor_info | **Flags** | **Type** | **Value** | **Units** | **Notes** | | --- | --- | --- | --- | --- | | Sensor | `string` | Any valid sensor type, such as `accel` and `gyro`. | N.A. | Queries attribute information for the specified sensor type. | | Log | `int` | 0 | 1 | N.A. | Enables or disables diagnostic (API) logs. | | help(h) | `int` | N.A. | N.A. | Displays command usage help. | | Duration | `int` | Positive values | Seconds | Specifies the wait time for the sensor attribute updates. | | Delay | `int` | Positive values | Seconds | Specifies the time delay before sending the sensor requests. | | default\_only | `int` | 0 | 1 | N.A. | If the `default_only` flag is set to `False`, UIDs of all the available sensors that support the specified data type are sent. If the `default_only` flag is set to `True`, only the UID of the default sensor availability is sent. | **Sensor info test examples** - Query the sensor attributes and generate diagnostic logs. ssc_sensor_info Copy to clipboard root@qcm6490:~# ssc_sensor_info ssc_sensor_info v1.86 SUID = 0xebd5604d09d379bca54dcf30ec041e0f NAME = ak0991x VENDOR = akm TYPE = mag AVAILABLE = true VERSION = 2.62.47 API = sns_mag.proto RATES = [1.000000, 10.000000, 20.000000, 50.000000, 100.000000] RESOLUTIONS = 0.150000 RANGES = [-4912.000000,4912.000000] DRI = false FIFO_SIZE = 0 STREAM_TYPE = streaming STREAM_SYNC = false DYNAMIC = false EVENT_SIZE = 16 OP_MODES = [LOW_POWER, LOW_NOISE] ACTIVE_CURRENT = 900 SLEEP_CURRENT = 3 HW_ID = 0 RIGID_BODY = display PHYSICAL_SENSOR = true PHYSICAL_SENSOR_TESTS = [3, 1] SELECTED_RESOLUTION = 0.150000 SELECTED_RANGE = [-4912.000000,4912.000000] SUID = 0xaddeaddeaddeaddeaddeaddeaddeadde NAME = da_test VENDOR = QTI TYPE = da_test AVAILABLE = true VERSION = 0.51.0 API = sns_da_test.proto STREAM_TYPE = on_change SUID = 0x69def905fea2fbac6a43ca273221a2eb NAME = aont VENDOR = QTI TYPE = aont AVAILABLE = true VERSION = 0.0.1 API = sns_aont.proto STREAM_TYPE = on_change SUID = 0xabababababababababababababababab NAME = suid VENDOR = QTI TYPE = suid AVAILABLE = true VERSION = 0.0.1 API = sns_suid.proto STREAM_TYPE = single_output SUID = 0xe12754a7007f27595e2541b4701e2275 NAME = registry VENDOR = QTI TYPE = registry AVAILABLE = true VERSION = 0.0.1 API = sns_registry.proto STREAM_TYPE = single_output SUID = 0xadfeadfeadfeadfeadfeadfeadfeadfe NAME = da_test_big_image VENDOR = QTI TYPE = da_test AVAILABLE = true VERSION = 0.49.0 API = sns_da_test.proto STREAM_TYPE = on_change SUID = 0x61ab5376b4a5c9aa58442ede47acd316 NAME = icm4x6xx VENDOR = TDK-InvenSense TYPE = accel AVAILABLE = true VERSION = 1.65.2 API = sns_accel.proto RATES = [12.500000, 25.000000, 50.000000, 100.000000, 200.000000, 500.000000] RESOLUTIONS = [0.000019, 0.000037, 0.000075, 0.000150, 0.000299] RANGES = [[-9.806650,9.806650], [-19.613300,19.613300], [-39.226601,39.226601], [-78.453201,78.453201], [-156.906403,156.906403]] DRI = true FIFO_SIZE = 200 STREAM_TYPE = streaming STREAM_SYNC = false DYNAMIC = false EVENT_SIZE = 16 OP_MODES = [LPM, NORMAL, HIGH_PERF] ACTIVE_CURRENT = [50, 240, 240] SLEEP_CURRENT = 6 HW_ID = 0 RIGID_BODY = display PHYSICAL_SENSOR = true PHYSICAL_SENSOR_TESTS = [3, 2, 1] SELECTED_RESOLUTION = 0.000299 SELECTED_RANGE = [-156.906403,156.906403] LOW_LATENCY_RATES = 1000.000000 PASSIVE_REQUEST = true Copy to clipboard - Query all *accel* sensor attributes. ssc_sensor_info -sensor=accel Copy to clipboard root@qcm6490:~# ssc_sensor_info -sensor=accel ssc_sensor_info v1.86 SUID = 0x61ab5376b4a5c9aa58442ede47acd316 NAME = icm4x6xx VENDOR = TDK-InvenSense TYPE = accel AVAILABLE = true VERSION = 1.65.2 API = sns_accel.proto RATES = [12.500000, 25.000000, 50.000000, 100.000000, 200.000000, 500.000000] RESOLUTIONS = [0.000019, 0.000037, 0.000075, 0.000150, 0.000299] RANGES = [[-9.806650,9.806650], [-19.613300,19.613300], [-39.226601,39.226601], [-78.453201,78.453201], [-156.906403,156.906403]] DRI = true FIFO_SIZE = 80 STREAM_TYPE = streaming STREAM_SYNC = false DYNAMIC = false EVENT_SIZE = 16 OP_MODES = [LPM, NORMAL, HIGH_PERF] ACTIVE_CURRENT = [50, 240, 240] SLEEP_CURRENT = 6 HW_ID = 0 RIGID_BODY = display PHYSICAL_SENSOR = true PHYSICAL_SENSOR_TESTS = [3, 2, 1] SELECTED_RESOLUTION = 0.000299 SELECTED_RANGE = [-156.906403,156.906403] LOW_LATENCY_RATES = [1000.000000, 2000.000000] PASSIVE_REQUEST = true Copy to clipboard **Output** The test application generates the following output: - Standard output on console - Result file ### Use the driver acceptance test to validate sensor drivers The `ssc_drva_test` driver acceptance test tool does the following: - Performs sensor driver validation and operates at the QSH sensor API layer. - Executes a range of sensor use cases, such as streaming the sensor data and batching a sensor at a selected sampling frequency. - Accepts the parameters directly from the command line and eliminates the need for compile-time options. This approach makes it a convenient and efficient tool to perform basic driver-level tests or validations at HLOS. ssc_drva_test [-sensor=] [-duration=] [-sample_rate=] [-batch_period=] [-iterations=] [-num_samples=] [-factory_test=] Copy to clipboard The following table describes the parameters used by the `ssc_drva_test` test application. Table : Parameters of ssc_drva_test | **Flag** | **Type** | **Value** | **Unit** | **Notes** | | --- | --- | --- | --- | --- | | `sensor` | `string` |

  • accel


  • gyro


  • sensor_temperature


  • pressure


  • mag


  • humidity


  • ambient_temperature


  • ultra_violet


  • proximity


  • ambient_light


  • rgb


  • hall


  • Any custom sensor added


| N.A. | Mandatory argument: limited to the available sensor types. | | `duration` | `float` | Positive values only | Seconds | Mandatory argument: sensor test duration in seconds. | | `sample_rate` | `float` | Positive floating point number values:



>
>
>

    >

  • -1: Maximum sampling rate


    • >

  • -2: Minimum sampling rate


    • >
| Hz | Mandatory for streaming sensors, optional for on-change sensors. | | `batch_period` | `float` | Positive floating point numbers | Seconds | This period is the same as the report period and indicates how long to buffer the samples and report outside of the low-power processor. | | `iterations` | `int` | Positive values only | N.A. | Provides the number of times the test must be repeated. | | `num_samples` | `int` | Positive values only | N.A. | Indicates the minimum number of samples intended to be collected. If a `num_samples` parameter is specified and the test does not collect enough samples during the test, the test sensor generates FAIL.


The `num_samples` parameter forces the test to run for a maximum duration between a specified duration or duration calculated by the following:

  • num_samples expected sample rate, where the expected sample rate is the rate at which the sensor is expected to serve.


| | `factory_test` | `int` |

  • 0 (SNS_PHYSICAL_SENSOR_TEST_TYPE_SW)


  • 1 (SNS_PHYSICAL_SENSOR_TEST_TYPE_HW)


  • 2 (SNS_PHYSICAL_SENSOR_TEST_TYPE_FACTORY)


  • 3 (SNS_PHYSICAL_SENSOR_TEST_TYPE_COM)


| N.A. | Selects the type of factory test (from the value column) that you want to run. | **Driver acceptance test examples** - Stream a single sensor at a selected sampling frequency for a known duration: ssc_drva_test -sensor=accel -duration=5 -sample_rate=500 Copy to clipboard root@qcm6490:~# ssc_drva_test -sensor=accel -duration=5 -sample_rate=500 6 ssc_drva_test version 1.27k 6 ssc_drva_test -sensor=accel -duration=5 -sample_rate=500 diag: Diag_LSM_Init: invoked for pid: 1141 with init_count: 0 diag:successfully connected to socket 3 diag: Diag_LSM_Init: done for pid: 1141 with init_count: 1 6 event_cb attribute event for da_test 6 event_cb attribute event for da_test 6 using da_test name=da_test, suid = [high addeaddeaddeadde, low addeaddeaddeadde 6 enter send_memory_log_req cookie: 6 6 exit send_memory_log_req 6 enter da_test runner. -rumifact=1 6 -time_to_first_event=233206 6 -time_to_last_event=-20008 6 -sample_ts=50267544823 6 -total_samples=2528 6 -avg_delta=37875 6 -recvd_phy_config_sample_rate=500 6 -random_seed_used=2926886043 6 -num_request_sent=2 6 -first_sample_timestamp=50171775915 6 received event: PASS 6 enter send_memory_log_req cookie: 6 6 exit send_memory_log_req 6 PASS Copy to clipboard - Batch a single sensor at a selected sampling frequency and report period for a known duration: ssc_drva_test -sensor=accel -duration=30.0 -sample_rate=100 -batch_period=2.0 Copy to clipboard root@qcm6490:~# ssc_drva_test -sensor=accel -duration=30.0 -sample_rate=100 -batch_period=2.0 3 ssc_drva_test version 1.27k 3 ssc_drva_test -sensor=accel -duration=30.0 -sample_rate=100 -batch_period=2.0 diag: Diag_LSM_Init: invoked for pid: 1413 with init_count: 0 diag:successfully connected to socket 3 diag: Diag_LSM_Init: done for pid: 1413 with init_count: 1 3 event_cb attribute event for da_test 3 event_cb attribute event for da_test 3 using da_test name=da_test, suid = [high addeaddeaddeadde, low addeaddeaddeadde 3 enter send_memory_log_req cookie: 3 3 exit send_memory_log_req 3 enter da_test runner. -rumifact=1 3 -time_to_first_event=15321140 3 -time_to_last_event=-13606286 3 -sample_ts=8591389823 3 -total_samples=2960 3 -avg_delta=184826 3 -recvd_phy_config_sample_rate=100.000000 3 -random_seed_used=3720387971 3 -num_request_sent=2 3 -first_sample_timestamp=8030694123 3 received event: PASS 3 enter send_memory_log_req cookie: 3 3 exit send_memory_log_req 3 PASS Copy to clipboard - Self-test for accelerometer (hardware self-test), which checks the health and basic functionality of the accelerometer sensor by running the built-in diagnostic routines: ssc_drva_test -sensor=accel -factory_test=1 -duration=10 Copy to clipboard root@qcm6490:~# ssc_drva_test -sensor=accel -factory_test=1 -duration=10 4 ssc_drva_test version 1.27k 4 ssc_drva_test -sensor=accel -factory_test=1 -duration=10 diag: Diag_LSM_Init: invoked for pid: 1439 with init_count: 0 diag:successfully connected to socket 3 diag: Diag_LSM_Init: done for pid: 1439 with init_count: 1 4 event_cb attribute event for da_test 4 event_cb attribute event for da_test 4 using da_test name=da_test, suid = [high addeaddeaddeadde, low addeaddeaddeadde 4 enter send_memory_log_req cookie: 4 4 exit send_memory_log_req 4 enter da_test runner. -rumifact=1 4 -time_to_first_event=0 4 -time_to_last_event=-2032137957 4 -sample_ts=10622073335 4 -total_samples=0 4 -avg_delta=0 4 -recvd_phy_config_sample_rate=0.000000 4 -random_seed_used=1840104635 4 -num_request_sent=2 4 -first_sample_timestamp=0 4 received event: PASS 4 enter send_memory_log_req cookie: 4 4 exit send_memory_log_req 4 PASS Copy to clipboard **Output** On the console command line, this test outputs `PASS` or `FAIL`, which indicates only the test execution status. ### Use the sensor workhorse test to perform stress test of sensors The `see_workhorse` sensor workhorse tool does the following: > > > - Operates specific sensors based on the command-line arguments. > - Streamlines sensor testing and data collection in various configurations. see_workhorse [-sensor=][-sample_rate=] [-batch_period=] [-calibrated=<0 | 1>] [-wakeup=<0 | 1>] Copy to clipboard Table : Parameters of see_workhorse | Flags | Type | Value range | Units | Notes | | --- | --- | --- | --- | --- | | `sensor` | `string` |

  • accel


  • gyro


  • sensor_temperature


  • pressure


  • mag


  • humidity


  • ambient_temperature


  • ultra_violet


  • proximity


  • ambient_light


  • rgb


  • hall


  • Any custom sensor added


| N.A. | Mandatory argument: Limited to the available sensor types. | | `on_change` | `int` | 0 | 1 | N.A. |

  • 0 selects using SNS_STD_SENSOR_STREAM_TYPE_STREAMING.


  • 1 selects using SNS_STD_SENSOR_STREAM_TYPE_ON_CHANGE.


| | `sample_rate` | `float` |

  • Positive floating point number values


  • -1: Maximum sampling rate


  • -2: Minimum sampling rate


| Hz | Mandatory for streaming sensors, optional for on-change sensors. | | `batch_period` | `float` | Positive floating point numbers | Seconds | Same as the batch period or report period. | | `calibrated` | `int` | 0 | 1 | N.A. |

  • 0: nop (default).


  • 1: if the sensor_type is gyro or mag, then also activate gyro_cal or mag_cal, respectively.


| | `wakeup` | `int` | 0 | 1 | N.A. |

  • 0: sets suspend_config wake-up to SEE_CLIENT_DELIVERY_NO_WAKEUP.


  • 1: sets suspend_config wake-up to SEE_CLIENT_DELIVERY_WAKEUP (default).


| | `display_events` | `int` | 0 | 1 | N.A. | Display sensor events in JSON format, using the event callbacks. | **Sensor workhorse examples** For instance, use the following command to stream the accelerometer data at the maximum rate for 10 sec: see_workhorse -sensor=accel -sample_rate=-1 -duration=10 -display_events=1 Copy to clipboard root@rb3gen2-core-kit:~# see_workhorse -sensor=accel -sample_rate=-1 -duration=10 -display_events=1 see_workhorse version 2.21 06:47:56.554 see_workhorse -sensor=accel -sample_rate=-1 -duration=10 -display_events=1 begin usta_get_sensor_list diag: Diag_LSM_Init: invoked for pid: 3119 with init_count: 0 diag:failed to connect to diag socket Diag_LSM_Init: Failed to open handle to diag driver, error = 111end usta_get_sensor_list por file: /etc/sensors/por_spec.txt not found. 06:47:57.922 psalt->begin() took 1367 milliseconds 06:47:57.922 get_sensor_suid( diag_sensor) 06:47:57.922 get_sensor_suid( delta_angle) 06:47:57.923 lookup: accel 06:47:57.923 suid = [high 61ab5376b4a5c9aa, low 58442ede47acd316] 06:47:57.923 -sensor=accel -rigid_body=[display] found suid = 0x61ab5376b4a5c9aa58442ede47acd316 06:47:57.923 is NOT POR. 06:47:57.923 has max_rate: 500 hz 06:47:57.924 begin iteration: 1 06:47:57.924 stream_sensor( accel) 06:47:57.924 + sample_rate: -1.000000 hz diag: Diag_LSM_Init: invoked for pid: 3119 with init_count: 0 diag:failed to connect to diag socket Diag_LSM_Init: Failed to open handle to diag driver, error = 11106:47:58.000 config_stream_sensor() complete rc 0 06:47:58.001 sleep(10) seconds "sns_client_event_msg" : { "suid" : { "suid_low" : "0x58442ede47acd316", "suid_high" : "0x61ab5376b4a5c9aa" } , "events" : [ { "msg_id" : 130, "timestamp" : 28628090051, "payload" : { "unknown_fields" : 1, "field_1" : 5 } } ] }, "Event Counter" : 1, "Time Elapsed" : 0 } "sns_client_event_msg" : { "suid" : { "suid_low" : "0x58442ede47acd316", "suid_high" : "0x61ab5376b4a5c9aa" } , "events" : [ { "msg_id" : 130, "timestamp" : 28628114513, "payload" : { "unknown_fields" : 1, "field_1" : 2 } } ] }, "Event Counter" : 2, "Time Elapsed" : 0 } 06:48:08.001 awoke 06:48:08.001 disable_sensor( accel) 06:48:08.024 disable_sensor() complete rc 0 06:48:08.024 end iteration: 1 06:48:08.024 msg_id: 130, num_events: 2, first_ts: 28628090051, last_ts: 28628114513, avg_delta: 24462.000 06:48:08.024 sleep(1.000) seconds 06:48:09.025 awoke 06:48:09.025 PASS see_workhorse -sensor=accel -sample_rate=-1 -duration=10 -display_events=1 PASS see_workhorse -sensor=accel -sample_rate=-1 -duration=10 -display_events=1 06:48:09.025 begin delete psalt 06:48:09.038 end delete psalt Copy to clipboard ## Sensing hub simulator (SHS) SHS enables you to build algorithms for QSH using a x86 Linux platform. See [Sensing hub simulator](https://docs.qualcomm.com/doc/80-P9361-25), for more information. ## Miscellaneous tools Use the following tools for the build environment and functional diagnosis: - Qualcomm® Hexagon™ DSP toolchain: Hexagon 8.4.07 toolchain for the build environment. - QXDM Professional™ Tool: A diagnostic client used for functional diagnosis and aDSP-side debugging. - The QSH framework can call the macros and APIs directly to send the debug information to print strings and log packets. - The QXDM logs are primarily used for the aDSP side debugging. For more information, see [Troubleshoot sensors](https://docs.qualcomm.com/doc/80-80022-7A/topic/debugging.html). - QXDM Professional requires a USB connection. The application processors have direct connectivity to a USB port, whereas the aDSP doesn’t have such connectivity. For more information, see [Qualcomm® Package Manager 3 Documentation](https://qpm.qualcomm.com/assets/userguide/external/book/0.UserGuide/UserGuide.html). Last Published: May 07, 2026 [Previous Topic Troubleshoot sensors](https://docs.qualcomm.com/bundle/publicresource/80-80022-7/topics/debug.md) [Next Topic Supported platforms](https://docs.qualcomm.com/bundle/publicresource/80-80022-7/topics/platform_setup.md)