0

I have a Millikey Response Box with a 1 000 Hz sampling rate and a light sensor with a 10 000 Hz sampling rate. I would like to measure end-to-end response time from the moment of a button press to a change on the screen triggered by the button press in my C++ program. I'm struggling to understand how to do it.

My idea was that, ideally, I would have the button press create a keypress event that holds a timestamp of when it was created at a 1 000 Hz sampling rate. My C++ program would handle this event at its own frequency by recording the high-frequency timestamp and triggering the brightness change on the screen. Next, the light sensor would pick up the change and generate its own keypress event at a sampling rate of 10 000 Hz. At the next cycle, my C++ program would pick up this event and get the actual end-to-end time by comparing the two high-resolution timestamps.

Is this idea sensible? If yes, how can I implement it?

So far I used GLFW to capture keyboard events and to get the timestamp in the key callback, but as far as I understand, that is not exactly the time when the key was pressed.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Mateusz Sadowski
  • 37
  • 1
  • 8
  • Do you have any available test points on the hardware? – Thomas Matthews Oct 15 '21 at 19:59
  • Desktop OSes generally have pitiful high precision timing capabilities. Even millisecond timing can be dodgy. I'd start with `std::chrono::steady_clock` ([avoid using `std::chrono::high_resolution_clock`](https://stackoverflow.com/questions/37426832/what-are-the-uses-of-stdchronohigh-resolution-clock) even though it sounds like the right tool for the job. It probably isn't) and see how good the results are. If it sucks, refine the question. – user4581301 Oct 15 '21 at 20:00
  • @ThomasMatthews I guess yes. See "MilliKey Timing Validation" on this [page](https://www.labhackers.com/millikey.html). I don't understand how should I use it in order to get accurate timestamps though. Could you explain? – Mateusz Sadowski Oct 15 '21 at 21:46
  • What you do is assert the test point before the action, then deassert the test point after the action. Hook up an o'scope probe or a logic analyzer to the test point. You may want to write an endless loop for benchmarking. You may want to trigger the oscilloscope on the assertion transition of the test point. – Thomas Matthews Oct 15 '21 at 22:06
  • That's waaaay more complicated than I thought it would be... but thanks! I will look into that – Mateusz Sadowski Oct 16 '21 at 07:39

2 Answers2

0

Trying to do all that with a computer and peripherals is likely going to lead you nowhere, because of the unknown and likely erratic latency in various parts of the chain.

So here is a trick I have used successfully to measure latency. I connected the light sensor to a sound generator. I then recorded the sound of the button being hit together with the sound from the sensor. Recorded at 96Khz, this will give you a very accurate and precise reading. You just have to measure the delay in an audio editor, or I guess you could have a stand alone program to analyse the audio too.

Dino Dini
  • 433
  • 3
  • 6
  • 1
    Another good trick, if you have low-latency DIO, is to set and clear a digital out line and take measurements on an oscilloscope. – user4581301 Oct 15 '21 at 21:10
0

The answer for me was to use LabStreamingLayer. I use App-Input to capture keyboard events, LabRecorder to capture the stream of these events, and then Python importer to parse the resulting XDF file. All the above runs and captures events in the background while the keypress triggers the screen change in my C++ program which is detected by the light sensor.

I'm sure that the other answers and comments make good suggestions for when one would want to implement this on a low level themselves. My question was also not refined since my understanding was limited, so thank you for the contribution anyway!

Mateusz Sadowski
  • 37
  • 1
  • 8