I have a code in Psychtoolbox calling Screen(‘flip’) at each iteration of some for loop. To explain briefly, the screen refresh rate is acquired at the beginning and the experiment time is divided by the refresh rate to give a timing array for each refresh rate.
Total_experiment_time=(1 minutes)=60 seconds;
%Block design stimulus
vbl = screen(‘flip’, grey_window);
Now, he starts a for loop that calls Screen(‘flip’) in each loop and starts recording keyboard right before finishing of the stimulus. Each loop is representing a vertical retrace and we want to get the reaction time when stimulus turns off (reaction to stimulus turning off).
if (i==1249 || i==2549) %representing one iteration before finish of stimulus
else if (i==1874 || i==(length(timeline)-2))
%representing one iteration before start of next stimulus or end of scan
(save keyboard data)
vbl = screen(‘flip’, window, vbl + 0.5*ifi);
I am totally aware that this is not the right way to write an experiment in Psychtoolbox but my reaction times are all messed up. They are long! and they are somehow showing a multimodal distribution! Any help to invert this would be appreciated.
Thanks in advance all
OS: windows 7, Hardware: DELL latitude E5570
As I think you appreciate, in general you shouldn’t use a basic loop of frame counts, as this is vulnerable to dropped frames and delays distorting the timing (especially relevant if you are stuck on Windows 7). You can use the
vbl returned by
flip itself as the timer, and use a set of defined real times to partition your experiment.
vbl = Screen('Flip',w); tStart = vbl;
while vbl <= tStart + 60
% draw stimuli here, better at the start of the drawing loop
Screen('DrawingFinished',w); % small ptb optimisation
% your logic to record keyboard here, also based on comparing timestamps, not frame-number
vbl = Screen('Flip',w,vbl+halfisi);
This will be more robust timing wise…
You are absolutely right. Unfortunately, this code is written by someone else with minimal experience with PTB. I would have written the code myself this way if I wanted to. But the problem is that the data is already collected and I need to find a way to see if I can invert them.
Note that the written code saves all the time stamps for each loop which could help correcting the reaction times.
The question that arises in my mind is that:
At the time when Screen(‘flip’) is called with ‘when’ argument, it waits (pauses) for the next video retrace. What does this pause do to the Keyboard recording? What happens if keyboard response happens during this pause?
As I understand it, KbQueue is asynchronous, i.e. it collects in the background unaffected by other things MATLAB is doing, at least the demo shows WaitSecs doesn’t block it.
Your inter-peak interval is around 10ms, which is not your flip interval (assuming 60Hz), so I surmise your keyboard hardware polling is what is responsible for the 10ms interval? If this is the case you probably need to use a best fitting gaussian to find the real peak.
If timing is important for your study (for your future studies), computer keyboards should NOT be used as they have lousy temporal fidelity. Use something like the RTBox, which has dedicated PTB support…
Thank you very much Ian-Max,
I have found the problem and it was about saving our data and has nothing to do with PTB so… problem resolved.
I am not sure about the forum rules but should I delete this thread?