Skip to main content
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
FlagsTypeValueUnitsNotes
SensorstringAny valid sensor type, such as accel and gyro.N.A.Queries attribute information for the specified sensor type.
Logint0 | 1N.A.Enables or disables diagnostic (API) logs.
help(h)intN.A.N.A.Displays command usage help.
DurationintPositive valuesSecondsSpecifies the wait time for the sensor attribute updates.
DelayintPositive valuesSecondsSpecifies the time delay before sending the sensor requests.
default_onlyint0 | 1N.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
FlagTypeValueUnitNotes
sensorstring
  • 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.
durationfloatPositive values onlySecondsMandatory argument: sensor test duration in seconds.
sample_ratefloat
  • Positive floating point number values
  • -1: Maximum sampling rate
  • -2: Minimum sampling rate
HzMandatory for streaming sensors, optional for on-change sensors.
batch_periodfloatPositive floating point numbersSecondsThis period is the same as the report period and indicates how long to buffer the samples and report outside of the low-power processor.
iterationsintPositive values onlyN.A.Provides the number of times the test must be repeated.
num_samplesintPositive values onlyN.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_testint
  • 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
6 ssc_drva_test version 1.27k
6 ssc_drva_test -sensor=accel -duration=5 -sample_rate=500
6 received event: PASS
6 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
3 ssc_drva_test version 1.27k
3 received event: PASS
3 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
4 ssc_drva_test version 1.27k
4 received event: PASS
4 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=<max | min | positive integer value>] [-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
FlagsTypeValue rangeUnitsNotes
sensorstring
  • 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_changeint0 | 1N.A.
  • 0 selects using SNS_STD_SENSOR_STREAM_TYPE_STREAMING.
  • 1 selects using SNS_STD_SENSOR_STREAM_TYPE_ON_CHANGE.
sample_ratefloat
  • Positive floating point number values
  • -1: Maximum sampling rate
  • -2: Minimum sampling rate
HzMandatory for streaming sensors, optional for on-change sensors.
batch_periodfloatPositive floating point numbersSecondsSame as the batch period or report period.
calibratedint0 | 1N.A.
  • 0: nop (default).
  • 1: if the sensor_type is gyro or mag, then also activate gyro_cal or mag_cal, respectively.
wakeupint0 | 1N.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_eventsint0 | 1N.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

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
06:47:57.923 suid = [high 61ab5376b4a5c9aa, low 58442ede47acd316]
06:47:57.924 stream_sensor( accel)
06:47:58.001 sleep(10) seconds
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: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

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