The HID is implemented using an Arduino Pro Micro Microcontroller, which offers the capability to emulate a human interface device, which is recognized and handled as HID-hardware, comes at a low price and is a controller commonly used for prototyping.

Furthermore, a correct button is needed as input key for the user.

In order to create a robust and easy to transport device, also an adequate enclosure is needed.

The device circuitry is very simple, since just the detection of a contact close has to be recognized. The button-circuit provided by the Arduino has been used (https://www.arduino.cc/en/Tutorial/Button, 5.12.18), triggering on a high input signal on one of the digital IO pins and using a 10 kOhm Pulldown resistor.

For providing an adequate experience close to the feeling of a consumer level keyboard key, a tactile switch had to be identified, which matches the characteristics of a consumer level keyboard considering the following aspects:

• Travel Distance
• Triggering Force
• Pressure Response Characteristics

Four different buttons in stock at the faculty workshop were analyzed by data sheet and a pressure response test was conducted with a prototype device provided by group supervisor Mr. Andreas Schmid. The results were compared to evaluated characteristics elevated for consumer level keyboard devices.

Both tests showed adequate results for the Marquardt 6425-series tactile switches, thus a model from the series was chosen for the prototype.

To rule out falsification through the device housing, the shape of the device enclosure was designed regarding similarity to a consumer level keyboard in the aspects of hand posture and button height. Also a symmetrical design has been chosen to allow usage for left-handers and right-handers.

Early informal tests during construction also showed, that the device would slip away during usage, so rubber feet were added to provide slipping.

Since the wooden enclosure of the device would resonate noisily with every click, a wooden bridge was added to dampen the click sounds and assimilate the acoustic response to an expected level.

The purpose of the device is to behave like a standard hardware keyboard and provide the capability to send a „Space“-Keystroke-Event. We used the ready-to-use Keyboard-Library providing HID-detection and -functionalities, published by the Arduino Community. (https://www.arduino.cc/reference/en/language/functions/usb/keyboard/, 7.12.2018)

The HID should provide the capability to

• register key presses
• fire the event after a defined amount of time (ms-fine)
• vary this delay according to a defined characteristics (standard deviation, ms-fine)

This goal was achieved by decoupling event-recognition and event-firing. When a keypress is registered during the recognition-update, a future trigger time is computed from the sum of the current timestamp and the desired latency time and registered in the „Future Event Array“, which is also scanned for „due“ events every tick. When a „due“ event is recognized, the HID library is triggered to transmit a „Space“-Keystroke. In the improbable case of multiple due firings during one tick, only one event will be sent.

Latency variance was computed using the Box-Muller-Algorithm, which provides normally distributed values, that can be parametrized by a standard deviation value. We used an already implemented version of the algorithm, fit for usage in Arduino projects (http://forum.arduino.cc/index.php?topic=114504.0 (8.11.2018)).

Caveat: When adding a negative deviation value to a base latency lower than the deviation, the value is clipped to 0, since we are not capable of generating negative latencies.

Especially when using the device at high latency values, it is not possible, to simply let the process sleep for a desired time to simulate latency, since all events occurring during the sleep would be ignored. Altogether, blocking „delay“ statements have been avoided.

During early stages of development, it became obvious, that connected buttons would retrigger multiple times, when pressed. The phenomenon is called „Bounce“ and is caused by small oscillations of the button's mechanics, causing the contact to rapidly close and reopen. („The Art of electronics“, Horowitz & Hill, Second edition, pg 506.) We used a firmware-side, non-blocking and easily configurable approach to cope with bounce (obtained at https://programmingelectronics.com/tutorial-19-debouncing-a-button-with-arduino-old-version/ (8.11.2018)).

The latency characteristics of the HID should be parametrizable through

• Average Latency
• Latency Standard Deviation

A serial interface has been implemented, allowing methods to set both of these values from a host device.

Furthermore, each triggered event should also allow insights on

• the currently set latency characteristics
• the actual simulated latency

The serial interface thus calls back those values to the host in json format.
In order to allow seamless and independent connection to a host-application, the „Pusher Bridge“ has been implemented, an expressJS web-service serving as abstraction layer. The bridge connects to the serial interface of the HID, transforms HTTP-requests to serial commands to set latency characteristics and records and saves latency logs received by the HID.

Before conducting the prestudy, the base latency characteristics of the device (average latency: 0, latency SD: 0) was measured with the „LagBox“ measurement device (Bockes et al., 2018) and amounted to:

• base latency: 2,111755 [ms]
• latency standard deviation: 0,4466074823 [ms]

These values are similar to the latency characteristics of the best performing device from the study of Bockes et al. (avg.: 2.2 ms, sd: 0.3 ms) (Bockes et al., 2018). Thus, we suppose, that the influence of the HID base latency characteristics will not negatively affect the results of the study.