Arduino Latency Meter

A simple DIY Arduino-based device to measure the input-to-action latency in 3D games.

1. How it works

a. It works differently

b. Advantages over other latency metering devices

  1. You don't need bullets to measure latency, so you never run out of ammo - you can (quickly) make as much measurements as you wish. As a result, the device can work autonomously to collect unlimited number of measurement samples, reaching a much higher accuracy.
  2. The measurement doesn't rely on the muzzle flash animation, which (depending on developer) may be rendered with a delay, producing incorrect results.
  3. You can measure latency in games that don't shoot guns (e.g. shoot arrows or explore)
  4. You don't need to place the device in the middle of the screen every time. It is unobtrusive enough that you don't even have to take it off.
  5. The device requires only one connected wire for operation.
  6. The device can even estimate the effective framerate - something the other devices cannot do.
  7. And of course, last but not least - the device is open source, cheap, and easy to make!

c. So what about the "click-to-photon"?

2. Building the device

3. Device placement

4. Operating the software

a. Programming the Arduino board

b. Using the Arduino IDE to interact with the software

Here is what this means:

c. Choosing the right scene for measurement

d. Interpreting the results

e. Understanding the "estimated framerate"

Lets start with the obvious first: there is no direct way to measure the framerate by observing the screen, especially if we are only observing a single point on screen. That is true for a mostly static image, or for an animation we have no control over. But in our case we DO have control over the animation - we are causing the image to move right and left.

As it turns out, the latency measurements are inherently "noisy" - i.e. they have a "built-in" measurement error (because physics), and the magnitude of that error depends on - you guessed it - the framerate! So by analyzing the latency measurements and measuring how "noisy" they are (i.e. measuring the standard deviation), we can conclude what the framerate of the game must be.

A few caveats:

f. Also, it blinks!

To assist with verifying the measurement results using a high-speed camera (read: sanity check), a red LED lights up immediately after the USB command to move the mouse is sent, and is turned off as soon as the movement is detected.

g. A final note...

To achieve the best results, the measurement is always done when going from darker patch to brighter patch (and not on the back stroke), because: 

  1. The speed of light response of the monitor pigment is not symmetrical going from dark to bright vs from bright to dark.
  2. Some (many!) monitors have a flickering backlight, which makes only the "dark to bright" measurement direction possible.