| Reference | Downloads | Github

Reaction Times Rounded to 16ms (Frame-rate)

OS = Win10
PsychoPy version 1.84.1 (BUILDER)
Frame rate 60Hz

What are you trying to achieve?
Hi, I am running simple lexical decision tasks and therefore interested in Reaction Times (RTs).

However, the data output shows that the reaction times have been rounded to the nearest frame (i.e., they are roughly multiples of 16ms). For example, several responses are 434ms, and several are 451ms, several are 467ms, with nothing in between. I’ve attached an excel file (1st sheet shows RTs; 2nd sheet shows the LOG) sorted by RTs to illustrate this.LexDecRT.xlsx (143.1 KB)

I have difficulty understanding why (since ultimately, RTs should be dependent on keyboard press rather than frame rate). It’s particularly worrying because I expect only small priming effects of 30ms in the experiment (which would be diluted by what I’ve described above)

What did you try to make it work?:
I’ve checked other timing properties of the experiment and they seem to be fine: the log file shows that the stimuli is being presented as it should be (e.g., a prime word appears for 4 frames/66.667ms, and is immediately followed by the target word).

I’ve also tried checking and unchecking ‘Sync RT to screen’, using different stimuli, using different PCs, etc. I have been using Psychopy builder for a week now and really do feel like I’ve read every (builder) demo and manual-page that I can, so would appreciate any suggestions about why this occurs, and if it can be fixed?

What specifically went wrong when you tried that?:
Reaction times were still rounded to the nearest frame (i.e., multiples of 16.666ms) (as outlined above). Thank you for your time.

Builder experiments are structured around a drawing loop and event cycle that is driven by the screen refresh rate. So the keyboard is checked once per screen refresh, leading to the granularity you are seeing. Effectively, the reported reaction time will lag the time the keypress becomes available for detection by a mean 8.33 ms on a 60 Hz display. This lag should be a rectangular (i.e. uniform) probability distribution of mean 8.33, minimum 0, maximum 16.66 ms.

  • Bear in mind that this is a small effect relative to the physiological variability within (and certainly across) your subjects.
  • Averaging means that small differences between conditions are still easily detectable with a granular clock, as long as you use sufficient trials. See the classic paper by Ulrich (1989), “Time resolution of clocks: Effects on reaction time measurement—Good news for bad clocks”:
  • Bear in mind that a standard computer keyboard can impose a lag which is much larger than this, plus some uncertain level of variability. If you are serious about measuring reaction times, look at specialised hardware rather than a keyboard.

There are a couple of ways to minimise the Builder granularity. The easiest is to simply run a faster display. e.g. a 120 Hz display will give a mean lag of 4.16 ms, range 0 - 8.33 ms.

The second is to look at using the ioHub library within PsychoPy. This runs asynchronously to the main psychoPy process and timestamps the keypresses at the time that they are detected. So even if you ask ioHub for a keypress only once every screen refresh, you will get the actual time it was pressed rather than the time you checked it. This mostly eliminates the lag due to your software, but does nothing to deal with the unknown lag and variability in your keyboard hardware.

1 Like

Thank you Michael for the clear response. I now understand that this should not be problematic for my results.
Best Wishes,