The Human Interface Device (HID) protocol serves as the communication framework for Pulse, enabling seamless interaction between the glove and the host device. This protocol conforms to the standard HID specifications, providing a reliable and widely supported method for transmitting data between peripheral devices and computing systems.

What is HID?

HID is a standardized communication protocol designed for human interface devices such as keyboards, mice, game controllers, and in this case, haptic gloves. It ensures compatibility across various platforms by defining a set of rules for data exchange between the input device and the host system.

How does it work?

In the context of the HID protocol, the concepts of input and output reports play a pivotal role in facilitating effective communication between Pulse and the host device. An output report serves as a structured data packet generated by the glove, containing information about the glove's tracking data. In this case, the report is continually updated at a rate of approximately 67Hz, providing a steady stream of real-time tracking information. The output report essentially acts as a one-way communication channel, conveying essential data from the glove to the host.

On the other hand, an input report is the conduit through which the host device communicates with Pulse, instructing it on the desired vibrations and variable force feedback. Within a single input report, the device receives commands for generating tactile sensations for all five fingers.

Within the input report for each glove, a set of 10 values is transmitted, specifically representing the "Pull" and "Splay" characteristics for each of the five modules. These values are distributed across the 15 byte input report, ensuring the efficient transmission of tracking data.

Breaking down the structure further, the "Pull" value is represented as an unsigned 14-bit integer, capable of ranging from 0 to 16,383. This 14-bit unsigned integer is distributed across the first two bytes of the input report.

Similarly the "Splay" value is characterized as an unsigned 10-bit integer, providing a range from 0 to 1023. This 10-bit unsigned integer is allocated within the last two bytes of the input report.

Below is a table showing the assignments of the 3 byte packet of a single module.

As shown in the table, byte 1 is shared between the "Pull" and "Splay" values. Thus, when working with the raw HID reports, parsing will be required in order to retrieve the integer value.

These three byte packets are placed into the input report in the order: Thumb, index, middle, ring, pinky.

Output Reports

Output reports are more straightforward than input reports as the data is sent much less frequently meaning packet size is less of a concern. An output report for is 20 bytes in size, meaning 4 bytes are dedicated to each module. For output reports, each byte corresponds on only one value, meaning there are no shared bytes like there are for the input reports.

The first two bytes are used to control the variable force feedback:

• Byte 0 - Spring endpoint 1. Expects a signed byte (-127 to 127.)

• Byte 1 - Spring endpoint 2. Expects a signed byte (-127 to 127.)

Things to keep in mind when setting these values:

• Endpoint 1 should always be higher than spring endpoint 2.

• By default endpoint 1 is set to 25 and endpoint 2 is set to 0

  • To increase the force increase endpoint 1

  • To decrease the force decrease endpoint 2

  • Setting endpoint 2 between 0 and 25 will provide a hard stop at that point.

The other two bytes are used to set the vibration:

• Byte 2 - Vibration Intensity. Expects an unsigned byte (0 to 255.)

• Byte 3 - Vibration frequency (Hz.) Expects an unsigned byte (0 to 255.)

Setting either of these to zero will disable the vibration functionality. By default it is disabled.

Bad Output Reports: In the case an output report does not match expected size of 20 bytes there are two possible outcomes:

• Report size > 20 bytes: Bytes after index 19 are discarded. Device functions as normal.

• Report size < 20 bytes: Missing bytes corresponding to a given module will fully extend that module and disable the both VFF and vibration feedback. Any available bytes in the report will be written that corresponding module. Output reports including a partially complete module packet (less than 4 bytes) may lead to unintended behavior.

After a bad output report is sent, a proper report may be sent afterword to revert any unintended behavior. Resetting the device will also resolve any potential issues caused by a bad report.

If you want to develop without our SDK, you will likely be using the HID API for your preferred platform such as the Unity Input System or Windows HID API. Before this, we recommend using this debug tool to get a feel for the functionality of the device. This tool lets you view the raw input reports and manually send custom output reports.

Bifrost Driver

The Pulse SteamVR driver allows users to use Pulse with existing VR titles. Try the beta today!

Bifrost Integration (Unity)