.USB-HID-Transport-v1.6
Customer Documentation
Customer Documentation: Neonode® Touch Sensor Module User's Guide : .USB HID Transport v1.6
When connected via USB, the sensor communicates in Full Speed (12 Mbit/s) in two modes: Raw HID mode (also called HID Pipe) and HID Touch Digitizer mode. HID Touch Digitizer mode is initiated automatically as soon as the sensor is plugged in. In order to use Raw HID mode, the sensor's operation mode must be changed. For more information, refer to Initializing Sensors.
HID Touch Digitizer Mode
The sensor acts as a HID Input device and communicates directly with the OS, and is completely plug and play.
Ubuntu 17.10 - 18.04
The sensor is not recognized as a touch screen in the Ubuntu versions 17.10 - 18.04. This has been fixed and works fine in Ubuntu 18.10.
Raw HID Mode / HID Pipe
This mode uses two HID Feature Reports to communicate with the host.
- Send data to the sensor by writing to Feature Report 1.
- Read data from the sensor by reading from Feature Report 2.
Refer to zForce Message Specification for examples of requests, responses and notifications.
USB Communication in Different Operating Systems
Depending on the system and programming language you are using to write and read from a feature report, the implementation differs. For example, in Windows, this is abstracted and the hid.dll offers a function to get and set feature reports, while in for example a UNIX based OS, you might have to implement your own function to get and set a feature report.
The communication heading below describes how to implement your own get and set feature report functions, using a control transfer.
USB Permission
Depending on operating system you might need explicit permission for your program to have access to the HID device.
How to Implement Custom Functions for Raw HID Communication
In order to communicate with the sensor the data flow type called control transfer should be used. The control transfer usually takes the following parameters:
- Request Type (int)
- Request (int)
- Value (int)
- Index (int)
- Data (byte array)
- Length (int)
- Timeout (int)
Writing to Feature Report 1
When writing to the sensor a full 257 bytes need to be sent, no matter how long the actual message is. Take a look at the code snippet below, to see how this could be done.
uint8_t operationMode[] = { 0x01, 0x17, 0xEE, 0x15, 0x40, 0x02, 0x02, 0x00, 0x67, 0x0F, 0x80, 0x01, 0xFF, 0x81, 0x01, 0x00, 0x82, 0x01, 0x00, 0x83, 0x01, 0x00, 0x84, 0x01, 0x00 }; // The first two bytes are the header. First byte is feature report, second byte is length of the following data.uint8_t data[257];memcpy(data, operationMode, sizeof(operationMode));int requestType = 0x00 | (0x01 << 5) | 0x01; // USB_HOST_TO_DEVICE | USB_TYPE_CLASS | USB_RECIPIENT_INTERFACEint request = 0x09; // SET_CONFIGURATION = 0x09int value = 0x0301; // 0x03 for feature report, 0x01 for feature report 1int index = 0x0000; int length = sizeof(data);int timeout = 0; connection.controlTransfer( requestType, request, value, index, data, length, timeout);
Reading from Feature Report 2
When reading from feature report 2, the message is always 258 bytes long.
uint8_t data[258];int requestType = 0x80 | (0x01 << 5) | 0x01; // USB_DEVICE_TO_HOST | USB_TYPE_CLASS | USB_RECIPIENT_INTERFACEint request = 0x01; // CLEAR_FEATURE = 0x01int value = 0x0302; // 0x03 for feature report, 0x02 for feature report 2int index = 0x0000;int length = sizeof(data);int timeout = 0;connection.controlTransfer( requestType, request, value, index, data, length, timeout);
HID Report Descriptor
The HID Report Descriptor is subject to change. The descriptor below is from firmware version 1.47.
Parsed reports by Report ID
Document generated by Confluence on Sep 11, 2025 11:01