Sensor testing tools - Qualcomm Dragonwing Documentation

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.

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=<sensor_type>] [-delay=<time_in_seconds>][-duration=<time_in_seconds>][-default_only=<1|0>][-log=<1|0>][-help]

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

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           = 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

Query all accel sensor attributes.

ssc_sensor_info -sensor=accel

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

Output The test application generates the following output:

Standard output on console
Result file

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=<sensor_type>] [-duration=<time_in_seconds>] [-sample_rate=<value_in_Hz>] [-batch_period=<value_in_seconds>] [-iterations=<value>] [-num_samples=<value>] [-factory_test=<value>]

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`	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.
`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

root@qcm6490:~# ssc_drva_test -sensor=accel -duration=5 -sample_rate=500
ssc_drva_test version 1.27k
ssc_drva_test -sensor=accel -duration=5 -sample_rate=500
received event: PASS
PASS

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

root@qcm6490:~# ssc_drva_test -sensor=accel -duration=30.0 -sample_rate=100 -batch_period=2.0
ssc_drva_test version 1.27k
received event: PASS
PASS

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

root@qcm6490:~# ssc_drva_test -sensor=accel -factory_test=1 -duration=10
ssc_drva_test version 1.27k
received event: PASS
PASS

Output On the console command line, this test outputs PASS or FAIL, which indicates only the test execution status. 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=<sensor_type>][-sample_rate=<min | max | number>] [-batch_period=<seconds>] [-calibrated=<0 | 1>] [-wakeup=<0 | 1>]

The following table describes the parameters used by the see_workhorse tool. 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`	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` `min`: Minimum sampling rate `max`: Maximum 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 30 sec:

see_workhorse -sensor=accel -sample_rate=max -duration=30 -display_events=1

root@qcm6490:~# see_workhorse -sensor=accel -sample_rate=max -duration=30 -display_events=1
see_workhorse version 2.04
20:22:15.406 see_workhorse -sensor=accel -sample_rate=max -duration=30 -display_events=1
begin usta_get_sensor_list

20:22:15.731 stream_sensor( accel)
20:22:15.731 + sample_rate: 500.000000 hz
20:22:15.838 config_stream_sensor() complete rc 0
20:22:15.838 sleep(30) seconds

"sns_client_event_msg" : {
 "suid" : {
  "suid_low" : "0x58442ede47acd316",
  "suid_high" : "0x61ab5376b4a5c9aa"
 },
 "events" : [
  {
   "msg_id" : 768,
   "timestamp" : 78497742089,
   "payload" : {
    "sample_rate" : 500.000000,
    "water_mark" : 1,

Sensing hub simulator (SHS)

SHS enables you to build algorithms for QSH using a x86 Linux platform. See Sensing hub simulator, 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.
- 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.

​Sensor functional test tools

​Sensing hub simulator (SHS)

​Miscellaneous tools

Sensor functional test tools

Sensing hub simulator (SHS)

Miscellaneous tools