none
Windows Sensor HID Descriptor limits for Custom Sensors RRS feed

  • Question

  • I'm using the Windows 8 Sensor API for custom sensor development, successfully using custom_value_1 through custom_value_15 (15 datafields + 2 feature datafields required for a Windows Hardware Certification).

    If I add custom_value_16, the behavior of the sensor is unpredictable. If I remove custom_value_16, the sensor behaves as expected.

    The HID report descriptor is as presented in the "HID Sensor Usages Annotations for Windows HID Sensor Class Driver" for custom sensor that will be Windows Hardware Certified. The size of the report descriptor is 505 bytes, per the IAR C/C++ Compiler listing, for the well behaved sensor.

    My goal is to pass as many datafields as I can in a single HID Custom sensor input report, which according the HID Sensor Usages manual, appears to be up to custom_value_28.

    Is there a known problem with using all 28 custom value datafields for a Windows custom sensor?

    Is there a better way to send many data?

    Using a report count greater than 1 for a custom_value also caused unpreditable behavior.

    Wednesday, March 12, 2014 3:07 PM

All replies

  • Thanks for your question.

    One clarification - are you running Windows 8 or Windows 8.1?

    Regards,

    lisa

    Thursday, March 13, 2014 1:09 AM
  • I'm running Windows 8.1. 

    Thursday, March 13, 2014 6:55 PM
  • Thanks for the info.  To help the investigation, can you describe what the "unpredictable behavior" is? 
    Friday, March 14, 2014 3:26 AM
  • Thanks for the replies.

    I have two test devices: one (REFERENCE) that only uses custom_value_1 and a second one (DUT) that I have added custom_values up to custom_value_16. 

    The DUT advertise on power-up.  Windows 8 discovery is with using "Add a Device".  With up to custom_value_15 defined in the DUT's HID report, "Add a device" will always discover the DUT, typically within 2-3 seconds.  Also, the DUT has a button to restart advertising, in the event of a timeout or disconnect.  So I will use "Remove Device" and readvertise, and again "Add a device" always discovers the device.  I can use the Sensor Diagnostic tool to monitor "Enter" and "Leave" events and I can see the expected data values.  Also, my windows 8 Sensor App finds the device

    Reference behaves like this also.

    Adding custom_value_16 to DUT, "Add a device" does not always discover the device on power-up.  Eventually, either by repeated power-up or pressing the button to restart advertising, discovery happens.  DUT does not appear in the Sensor diagnostic tool until after these repeated power-up and readvertising. 

    REFERENCE worked ok.

    Removing custom_value_16 from DUT, advertising and connecting was back to normal.  "Add a Device" immediately found the DUT.

    The devices use the Texas Instrument Bluetooth Low Energy stack and I've posted this problem in the TI.COM  forum as well.

    Hopefully, you can verify that using all 28 custom_values is really supported by the Windows 8.

    Friday, March 14, 2014 11:49 AM
  • Thanks for the details.

    How does the Bluetooth Low Energy device appear as a HID sensor device? Do you install a third party driver from TI?

    Saturday, March 15, 2014 1:31 AM
  • Yes, the device does appear as an HID sensor device and I have used the Windows Sensor Diagnostic tool to verify connection, feature, and report communications. 

    Viewing the "Device Properties" show bluetooth low energy, HID properties, and Sensor properties, everything is as expected.

    I also have a Windows 8.1 application using Visual Studion 2013 C++.  This application was developed from the Ambient light sensor example and works fine (i.e. the manager event and sensor event objects detects and manager sensor events, including getting sensor data.


    • Edited by JJones7432 Tuesday, March 18, 2014 1:21 PM
    Tuesday, March 18, 2014 1:07 PM
  • Thanks for the description. Sounds like the device unexpectedly stops advertising over Bluetooth LE if the custom values exceed 16. This could be a bug on the device side.

    Tuesday, March 18, 2014 3:50 PM
  • I, also, suspect a BLE stack problem on the device side and I've posted a description of the problem in the TI.com "Low Power RF Bluetooth® Low Energy & ANT Forum".  No reply yet as to any HID report descriptor size limits.  And since there's no explicit support for Windows 8 Sensors in the TI BLE stack, there no mention of using Custom_values_1 through 28.

    However, I did find an post in the blogs.msdn.com (http://blogs.msdn.com/b/usbcoreblog/archive/2014/02/14/reducing-the-size-of-hid-descriptors.aspx).  Apparently there is a 4k limit for USB HID report descriptors.  My HID report descriptor size is 505 bytes, according to IAR compiler listing, well within the 4K limit.

    However, that post got me thinking that there may be other USB HID/Windows 8 sensor limits.

    Tuesday, March 18, 2014 4:57 PM
  • That limitation applies to HID/USB devices.  Unless your BLE device routes HID packets over USB, the HID/USB path won't apply.

    To see what the HID stack looks like, you can go to Device Manager, under "Human Interface Devices", find the devnode for your device, and then right click Properties -> Driver tab -> Driver Details.

    You should see a list that starts with hidclass.sys, hidparse.sys, followed by the transport-specific HID driver. Knowing what the transport-specific HID driver is will help determine whether this is a HID/USB device.

    Tuesday, March 18, 2014 5:16 PM
  • I am using a BLUETOOTH 4.0 USB Adapter.  (My Window 8 system did not have built-in bluetooth 4.0.  So, as I understand USB, BLUETOOTH and Windows Sensor, the transport layer over USB.

    Monday, March 31, 2014 11:55 AM