Hello,
I have just finished reading the great book by Jon and Michael. I have a few questions on the section “RT precision”. Based on my understanding of previous posts on this forum, it seems to me that RTs are tethered to the monitor’s refresh rate when presenting visual stimuli (and using Builder). For example, if I use a 60Hz monitor, the maximum RT resolution I can expect is 16.67 ms. However, I can’t find this information in the book, so I am wondering if it is true. I noticed that there is a Cedrus component in Builder which has a 2-3ms temporal resolution so I suppose that the polling rate is not constrained by the monitor’s refresh rate. If it is, what is the benefice of using expensive response devices such as a Cedrus pad if the polling rate cannot be increased?
Best,
Jeanne
Hi Jeanne,
Thanks for the kind comments. The issue here is that mice and keyboards don’t contain a clock. When a key is pressed or a mouse button clicked, that event just goes into a queue (also known as a buffer) for programs to access when they are ready. So when we use PsychoPy to check the keyboard buffer and find a keypress there, we have no idea when it occurred, except that it was in the period since we last checked (up to 16.7 ms ago if we are checking once per refresh on a 60 Hz screen, with a mean lag of 8.33 ms).
This is why we often need to flush that buffer (in Builder components, this is what the “new clicks only” and “discard previous” settings are for). i.e. at the start of a trial, there may be a key press in the buffer that was actually made several seconds ago, say during a rest period in between trials when we weren’t monitoring the keyboard or mouse.
Response boxes, meanwhile, like the Cedrus and others, run their own internal clock. We can send a reset signal so that its clock becomes synchronised with PsychoPy’s own time base. When we get a response from that device, we get information not only about what happened, but also a time value. We could be quite late in checking it, but that doesn’t matter as the time stored for that event by the hardware should be correct. So this is the advantage in using dedicated response hardware (they also aren’t so prone to other issues of lag and variability that plague consumer devices like keyboards).
It is possible to get timing of regular keyboard and mouse events that isn’t constrained by the drawing loop, but that involves some code. If the stimuli are static, we can stop updating the screen and just very quickly cycle through a loop checking for responses, but that isn’t compatible with Builder experiments which rely on sticking to the drawing cycle. Within Builder, we can use code components to check for responses using the ioHub library, which runs in a separate process to PsychPy and can check for events at a very rapid rate. At some point, we’d like to switch over to using that for the Builder components so users don’t have to handle it themselves, though.
So in essence, with some devices (like the keyboard and mouse) the timing resolution is related to how often we poll the device in software. But with a dedicated response box (as well as having better inherent lag and variability) the timing accuracy shouldn’t be constrained by polling rate at all. In theory, we could just get responses once at the end of the experiment, and they would be returned with all of their associated event times.
Thank you very much Michael for the clarifications.