I ran an experiment in which participants typed a word for each trial, with reaction times saved for each keypress. Reviewing the data, it seems that there’s an occasional issue with two keypresses occurring within the same frame and therefore being assigned the same reaction time in the csv data file.
Looking at the logfile, it has more precise times for the keypresses, e.g.:
1004.2786 DATA Keypress: o
1004.2797 DATA Keypress: r
while the csv just lists one reaction time for the two letters because they are so close together. (ie if this was a five-letter word there would be only four reaction times listed)
I’m glad to have these values in the logfiles, but there are probably a couple thousand missing values so I certainly can’t comb through them all manually. Just wondering if anyone has dealt with something similar and knows a good way to pull the values from the logfiles and integrate them with the csv files? I know some coding and could probably figure it out eventually, but it seems like something that must happen fairly often, so if anyone has a shortcut I’d really appreciate it!
These probably aren’t meaningfully different, but to answer that better, we need to know how the keypresses were collected. e.g. a common pattern is to call event.getKeys() once per screen refresh. If your monitor is running at a typical 60 Hz, then you don’t really know when the keys were pressed: it could be anytime in the last 16.666 ms. This dwarfs the time differences logged above. You do get the order of keypresses though, so you know which was pressed first. But the time value is the time you call event.getKeys(), not the time the keys were actually pressed. Bear in mind that if you are using a standard keyboard rather than some dedicated response hardware, then there is also some unknown lag and variability associated with the combination of the keyboard and the polling of it. This will also dwarf the difference in the times posted above, possibly by tens of milliseconds.
But as above, we need to know how these keypresses were gathered (i.e. are you using custom code that runs in a tight loop, or the standard Builder-style arrangement of checking oncer per screen refresh) to say much more.
There are ways of getting better time measurement of keypress events (on the software side at least), but that is another story…
Yes, I used event.getKeys() with each frame. I’m aware of the lack of precision from the refresh rate and the hardware, but I didn’t realize until you pointed it out that the logfile times wouldn’t have anything to do with the timing of two keypresses within the same frame. Now I suppose my coding question just got a lot easier because all of the missing values are just < 16ms, and the methodological question of what to do about that got a lot harder. Oh well, lesson learned. Thanks for the explanation — I’m embarrassed to say I noticed the problem at least a week ago and never pieced it together.
There are alternatives to using the psychopy.event module to collect key presses. These have the advantage of attaching an actual time to each keypress corresponding to when it was actually pressed (subject to all the normal hardware lag and variability caveats) rather than when you call the function to check what has been pressed. Currently this requires use of the iohub library but there is a new keyboard module that has been developed for PsychoPy and will likely effectively replace the event module, while still being relatively easy to use (iohub is very powerful but also correspondingly complex).
This will get around the 60 Hz limitation: even if checking once per frame, you’ll get an actual time per keypress. I don’t think it is too far off from being incorporated into a new release.