Back to Pulse Basics

HID Interface


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.

Input Reports

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:

Things to keep in mind when setting these values:

The other two bytes are used to set the vibration:

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:

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.

Testing Tool

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.

To begin, click Connect. This will bring up the list of available HID devices.

Now connect to the desired device. For the right hand this will be Unknown Device (1915:EEE0), for the left it is Unknown Device (1915:EEE1)

Once connected you will see two things: On top is the interface area, where you can view input reports and send output reports.

Below is the Device Info section, which highlights the device's characteristics.

You may notice that tracking data has immediately filled the input report section. This data will be constantly streamed from the device at 67 times a second. It is organized like so:

The first byte is dedicated to the report ID which specifies it as an input report. The other 15 bytes contain the tracking data itself, explained in the Input Reports section. Side note: this tool displays bytes in hex.

In order to control the haptics, you will need to send an Output Report here:

This debug tool uses hex values to represent bytes. If you are not familiar, you can use this conversion tool. Before converting, please make sure to set the encode type to 8-Bit Signed Integer (I8.)

To create an output report, first specify the report ID. In this case, it will always be 02. Next, write the 4 bytes needed for each modules (20 bytes total) based on the structure explained in the Output Report section.  Here's an example:

The first byte is 02 as it is always required to specify the report ID. The next 4 bytes are 

The values are repeated four more times in order to send the same data to all five modules. There should always be 21 bytes total in your report. These specific values will likely not result in any noticeable changes as it merely sets the "spring" to have a neutral force.

Here are a few more examples you can try:

 02‏‏‎‏‏‎ ‎23‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎23‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎23‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎23‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎23‏‏‎ ‎00‏‏‎ ‎00‏‏‎ ‎00 

Sets a high force on all fingers.

 02 19 0F 00 00 19 0F 00 00 19 0F 00 00 19 0F 00 00 19 0F 00 00 

Sets a neutral force with a hard stop half the length of the band.

 02‏‏‎‏‏‎‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 64‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 64‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 64‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 64‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 64‏‏‎‏‏‎ 14 

Medium force. Intense vibration.

 02‏‏‎‏‏‎‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 32‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 32‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 32‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 32‏‏‎‏‏‎ 14‏‏‎‏‏‎ 19‏‏‎‏‏‎ 00‏‏‎‏‏‎ 32‏‏‎‏‏‎ 14 

Medium force. Low vibration.

Bifrost Driver

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

Bifrost Integration (Unity)

SteamVR Package

OpenXR Package

Coming Soon!

Bifrost Integration (UE)

Coming Soon!