# Test and troubleshoot sensors ## 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 facilitates 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*. | – | Queries attribute information for the specified sensor type. | | Log | `int` | 0 | 1 | – | Enables or disables diagnostic (API) logs. | | help(h) | `int` | – | – | 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 | – | 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](mailto:root%40qcm6490):~# 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 - Query all *accel* sensor attributes. ssc_sensor_info -sensor=accel Copy to clipboard [root@qcm6490](mailto:root%40qcm6490):~# 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 #### 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


| – | Mandatory argument: limited to the available sensor types. | | `duration` | `float` | Positive values only | Sec | 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 | Sec | 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](mailto:root%40qcm6490):~# 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 - 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](mailto:root%40qcm6490):~# 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 - 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](mailto:root%40qcm6490):~# 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 **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 | NA |

  • 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 Copy to clipboard 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, 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/bundle/resource/topics/80-P9361-25/user_guide.html), 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: It’s a diagnostic client. - 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/bundle/resource/topics/80-70030-7A/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 [User Guide - Qualcomm® Package Manager 3 Documentation](https://qpm.qualcomm.com/assets/userguide/external/book/0.UserGuide/UserGuide.html). ## Verify sensors You can determine whether the configured QSH functionalities are operating properly or require attention for any discrepancies using the tools available for verifying these functionalities. You can use the test tool or the QXDM Professional tool to examine the configured settings and take the necessary action. **Use test tool to display sensor attributes** The `ssc_sensor_info` test tool verifies the QSH functionality and lists the supported sensors with their capabilities. This test tool runs on the HLOS. ssc_sensor_info Copy to clipboard The following shell output lists all the supported sensors and their attributes: [root@qcm6490](mailto:root%40qcm6490):~# 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 For troubleshooting common issues, see [Troubleshoot sensors](https://docs.qualcomm.com/doc/80-70030-7/topic/debug.html#debug). **Use QXDM Professional to display sensor logs** The following QXDM output shows the verification/confirmation logs for all the supported sensors and their attributes in a low-power processor: [ 123/ 2] MSG 18:47:22.898750 SNS PLATFORM/High [sns\_registry\_parser.c 2099] REG INIT DONE… ts=63248955 [ 122/ 1] MSG 18:47:22.925000 SNS FRAMEWORK/Medium [ sns\_diag\_service.c 1072] Sensor registry Vendor:QTI SSID:53 registered with diag [ 122/ 1] MSG 18:47:22.925000 SNS FRAMEWORK/Medium [ sns\_sensor.c 769] Populating sensor b2926130 in island: 2, with SUID e12754a7 007f2759 5e2541b4 701e2275 [ 122/ 2] MSG 18:47:22.925000 SNS FRAMEWORK/High [sns\_attribute\_service.c 584] Sensor : registry, suid\_populated : 1, available : 1 [ 122/ 2] MSG 18:47:22.925000 SNS FRAMEWORK/High [sns\_attribute\_service.c 594] Avail: B2926130 registry [ 123/ 2] MSG 18:47:22.925000 SNS PLATFORM/High [sns\_registry\_sensor.c 284] Successfully initialized registry [ 122/ 1] MSG 18:47:22.925000 SNS FRAMEWORK/Medium [sns\_stream\_service.c 150] Created data stream to Sensor ‘registry’ (b2926130) from Sensor ‘suid’ (b2922018): b296fd28 [ 122/ 1] MSG 18:47:22.925000 SNS FRAMEWORK/Medium [sns\_stream\_service.c 686] Add request b296fdc0 on stream b296fd28 (length 20; ID 512) [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [sns\_stream\_service.c 548] Process request for Sensor b2926130 on b296fd28 [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [ sns\_suid\_sensor.c 1050] send\_suid\_event dt=registry, default=1 [ 123/ 2] MSG 18:47:22.926250 SNS PLATFORM/High [ sns\_q6\_pm.c 365] Deregister\_client: B2927B30 [ 123/ 2] MSG 18:47:22.926250 SNS PLATFORM/High [sns\_registry\_sensor.c 366] Processed : SSCRPCD UP Signal [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [ sns\_suid\_sensor.c 1050] send\_suid\_event dt=registry, default=1 [ 122/ 1] MSG 18:47:22.926250 SNS FRAMEWORK/Medium [ sns\_data\_stream.c 551] sns\_data\_stream\_deinit b29231d0 removing=0 [ 122/ 1] MSG 18:47:22.926250 SNS FRAMEWORK/Medium [sns\_stream\_service.c 686] Add request b2927b30 on stream b29231d0 (length 0; ID 120) [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [ sns\_suid\_sensor.c 1050] send\_suid\_event dt=registry, default=1 [ 123/ 2] MSG 18:47:22.926250 SNS PLATFORM/High [ sns\_gdsc\_island.c 109] gdsc\_client\_cnt(2), sns\_gdsc\_mode(1) [ 122/ 1] MSG 18:47:22.926250 SNS FRAMEWORK/Medium [sns\_stream\_service.c 150] Created data stream to Sensor ‘timer’ (b2118e08) from Sensor ‘power\_sensor’ (b2922c78): b2931c48 [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [ sns\_suid\_sensor.c 1050] send\_suid\_event dt=registry, default=1 [ 122/ 1] MSG 18:47:22.926250 SNS FRAMEWORK/Medium [sns\_stream\_service.c 686] Add request b2123580 on stream b2931c48 (length 16; ID 512) [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [sns\_stream\_service.c 548] Process request for Sensor b2118e08 on b2931c48 [ 122/ 0] MSG 18:47:22.926250 SNS FRAMEWORK/Low [ sns\_suid\_sensor.c 1050] send\_suid\_event dt=registry, default=1 For more information about an individual sensor level verification, see [Tools](https://docs.qualcomm.com/doc/80-70030-7/topic/test_troubleshoot.html#test-tools). ## Test sensors on platform To use a sensor test application, see [Test sensors on the Dragonwing RB3 Gen 2 Development Kit](https://docs.qualcomm.com/doc/80-70030-7/topic/platform.html#test-sensors). Next steps - [Troubleshoot sensors](https://docs.qualcomm.com/doc/80-70030-7/topic/debug.html) Last Published: Jun 15, 2026 [Previous Topic Calibrate sensors](https://docs.qualcomm.com/bundle/publicresource/80-70030-7/topics/calibrate.md) [Next Topic Troubleshoot sensors](https://docs.qualcomm.com/bundle/publicresource/80-70030-7/topics/debug.md)