XLAT: Testing the Testing Device

What is XLAT?

Not a Finalmouse product in the strict sense, XLAT has been conceived as a device to accurately measure the latency of the UltralightX in particular and mice in general. Latency measurement is supported for both clicks and motion. In principle, the method for measuring click latency is the same as the one used for Nvidia's LDAT or a USB protocol analyzer. With the mouse plugged into the XLAT and the button in question interfaced with XLAT as well, the XLAT measures the time between button actuation (press or button-down) and the USB packet containing the click event data. The same method is employed for motion events, though in that case, the motion pin on the sensor is interfaced, and the time between it being triggered and the first USB packet containing motion data will be measured. Hence, only stationary-to-motion latency can be measured, but not continuous or motion-to-motion latency. Unlike LDAT or a USB analyzer, XLAT is self-contained and does not require running software on a host PC. On the other hand, given that most mice require being connected to a host to change latency-relevant settings, already being connected to one may be viewed as advantageous from a workflow perspective.

As mentioned, the XLAT is neither built nor sold by Finalmouse. Rather, only the firmware is provided, which is open-source and available on their GitHub. In order to build an XLAT, an STM32F746G-DISCO development board is required, which is then flashed with the XLAT firmware. The process is described in detail on their GitHub and is rather easy. In addition, by connecting the XLAT to one's PC, one can also log the data through a virtual COM port, the process of which is described in the GitHub wiki. The output can be read by any suitable terminal such as PuTTY. Personally, I've opted for KiTTY Portable.

XLAT in Practice

When working with the XLAT, there are several things to keep in mind.

Interfacing is done by connecting the signal wire to the signal pin of the switch in question, whereas the ground wire needs to be connected to the ground pin of any switch. For wired mice, the USB cable already functions as a ground, hence only signal needs to be connected. When trying to identify a suitable ground on wireless mice, first testing the mouse in wired mode to identify the correct signal pin therefore is a suitable approach. Alternatively, those owning a volt or multimeter can of course use those to determine ground, too.

On mice using optical switches, there won't necessarily be switch pins capable of being interfaced available. In those cases, one has to find a suitable test point or resistor, which typically can be identified by following the traces from the switch, or by simple trial and error.

Many mice these days employ various solutions to prevent so-called slam-clicking, which describes inadvertent button actuation upon resetting the mouse after lift-off. Typically, this is done by applying additional defer-type debouncing whenever a lift-off is detected. Hence, in order to get click latency numbers representative of actual usage, one has to make sure that the sensor is covered during testing. More specifically, the sensor needs to actually be tracking, and on mice basing this distinction on a determination of SQUAL, the surface needs to be one that allows the sensor in question to track. Of course, the easiest way to achieve this is by leaving the PCB where it belongs, i.e., the mouse, and on a regular mouse pad.

The XLAT offers two main ways of measuring click latency. The first one is manual actuation. With this method, the switch is manually closed by simply pressing down the plunger by hand. While straightforward in principle, pressing a button several hundred times can get tedious. Accordingly, the second method called "trigger" may be preferable, which closes the contact electrically and repeats this 1000 times at a fixed albeit slightly randomized interval. However, trigger should only be used for mechanical switches, as it will produce either no or inaccurate results for optical switches.

There is an oddity in relation to how trigger behaves compared to manual actuation. Compare the values of three different runs using the same mouse (Logitech G203 Prodigy) logged with manual actuation to the left to the ones logged with trigger (middle) and finally, the values logged with LDAT (right). As you can see, trigger behaves unlike the others in that each new value only ever increases by at most a single digit, and it does so continually. Alternatively, it may start at a higher value and then decrease continually by at most a single digit. Given the way USB polling and the processing of clicks work, the data output by XLAT cannot possibly be representative of the way the clicks actually are sequentially ordered. Note that this does not always apply, as on the UltralightX in wired mode, for instance, trigger does not behave like this.

XLAT: The Numbers

In theory, manual actuation and trigger should be two different ways of arriving at the same outcome. In truth, however, this is not the case, and both methods frequently differ in regard to both the average and standard deviation of output data. To reflect this difference, both average and standard deviation for XLAT (manual), XLAT (trigger), and LDAT are given below. Only mice utilizing mechanical switches are included, as trigger will give invalid results for optical switches. For manual actuation, 500 samples have been logged, whereas for trigger, the default 1000 samples have been logged. For trigger, a non-1000 sample count will typically net non-repeatable results.

¹ With manual actuation, in roughly 1 out of 100 samples significant outliers are present. These have been deemed anomalies and thus been omitted from the calculation.

Given that the values gathered by using manual actuation or the trigger function are equally valid, this leads to the methodologically undesirable situation that a testing device produces two incompatible sets of results, and one essentially is prompted to pick the value more to one's liking. In fact, given that both results cannot be true at the same time, one may be inclined to conclude that they are both false. The exception to this is the UltralightX, the results for which make perfect sense throughout. Hence, it stands to reason that any inconsistency observed for non-ULX mice likely isn't device-related or due to possible user error.

Looking at the numbers more closely, the most interesting sets of values are for the Aria XD7 and M64. Both mice are using the same MCU and firmware, and the only difference is what debounce time they are set to, which is 1 ms for the former and 2 ms for the latter. Hence, all other things being equal, the average for each needs to be exactly 1 ms apart. For LDAT, this condition is met. While XLAT (trigger) matches LDAT on the M64, it does not on the Aria XD7. With manual actuation, the values are neither 1 ms apart nor do they match the results for trigger or LDAT, and this applies regardless of whether the calculation is corrected for outliers or not. Another oddity is the fact that with manual actuation, standard deviation is higher on the Aria XD7 than on the M64, despite the average being lower.

Overall, while I believe that XLAT fails to meet its proclaimed standard ("single source of truth"), it serves as a viable and most importantly easily accessible, as well as more affordable alternative to other solutions such as a USB protocol analyzer or NVIDIA's LDAT, provided it is correctly used and one is aware of its current limitations. The emphasis here is on "current," as being open-source, anyone is free to try their hands at the firmware themselves. In addition, Finalmouse likewise is constantly improving things; for instance, just recently commits addressing the "counting up/down incrementally" issue with the trigger function have been made.