Response time bining

I try to analyze the data. But I find the response time show a trend. Response time is binning. See the image below. It is correlated to frame refresh rate. Does anyone know how to solve the problem? I want to collect accurate the response time. Instead of bias by frame refresh rate.


can you explain what is depicted on the y-axis? There is hardly a screen refresh-rate of 0 or 1.

BTW, the keyboard-component has the option to sync with the screen or not. Did you uncheck this option?

Best wishes Jens

By default a win.flip() call stops everything else, so a loop with win.flip() will only check key responses once per frame. As @JensBoelte said, there’s an option to have the keyboard component in the builder/hardware.keyboard object in the code track RT separately from the screen refresh rate, but you have to explicitly set it.

Is this a project you made completely with code or is it builder-based?

Hi Jens
Y axis is probability of participant making correct answer. It’s cumulative distribution function
Sorry, I did not specify the condition. I am using mouse. I find to sync with screen last night.
It still show same pattern.

It starts from builder based. But I need to implement some code, so I compile the code from builder and change it to coder based.

Is it possible to track RT within screen refresh rate? If participant makes a response before screen refresh, I can still record it.
I read the discourse yesterday. I found someone said the builder has limitation can only record 16.5 ms. Is it possible to I use coder and avoid this problem? Thanks.

That’s old information. The builder can do it now, as long as you’re using a 2022 or 2023 version of PsychoPy.

In the builder, open your keyboard component and go to the “Data” tab. There should be a check-box that says “Sync timing to screen”. If you un-check this box, RTs should be millisecond-accurate and no longer affected by the refresh rate.

Thanks for replying. I check my psyexp. It’s unchecked sync.Should I check it?

No, you should leave it un-checked. If it’s un-checked that should mean the keyboard responses are not tied to the refresh rate. Are you still seeing the binning?

If so, what version of PsychoPy are you on, and can you share your Psyexp file? I want to see if there’s some reason that might not be behaving as expected.

dotstwo_ver4.psyexp (68.5 KB) (62.0 KB)
Yes, I still see binning

I attached the psyexp that I compile the code. I do other work in .py file. I am not sure if it is I calculate RT on my own. because the RT in csv shows wrong RT, I use routineTimer.addTime(-2.566700) to get RT.

Apologize for the messy code.

Ahh, I think I see part of the confusion. This is the RT from the mouse, right? I was thinking this was a keyboard component.

As far as I can see it’s set up correctly, but looking closer at the code, I don’t think it’s possible to really make it desync from the frame-rate unfortunately, at least not from the builder. It might not be possible from the coder either, looking at how mouse.getPressed works, but there’s something going on with pyglet event handlers that I don’t know much about.

@jon might know more about how the mouse system works. Is the timing genuinely separate from the refresh, or do the pyglet events only trigger on screen refresh as well?

In any case the keyboard component with the PTB backend can be completely desynced from the framerate, so if you can use key-presses instead then definitely won’t be an issue.

Important: There’s some confusion here about the setting “sync to screen refresh”. If you’re measuring a response time to a visual stimulus then this option should be checked It refers to synchronising the start time of the RT to the screen refresh when the stimulus was first presented. That option has nothing to do with the polling of the keyboard/mouse. The polling, using either iohub or ptb, is always fully asynchronous from the screen and for pyglet it’s always synchronous. To reiterate, this setting is about synchronising the start time of the stimulus which is important for visual stimuli.

The issue in the original post is indeed to do with using the mouse rather than the keyboard. Mouse clicks aren’t like keyboard events though - they aren’t really events at all. We merely check the mouse state and see if it changed at all. So far I’m afraid @jonathan.kominsky is correct that this is only being done in the main loop so it gets tied to the window loop. In order to solve that issue, for now, Jonathan is correct that you should use the keyboard instead of mouse

But also do leave the sync option turned on! :slight_smile: