Timing issue in online stop task

SanderLos

Hi,

I have programmed a stop task with 25% stop-signal trials among 75% go trials. The stop signal delay (SSD) is adjusted after each stop trial (-50 ms if the subject responds; +50 if the subject withholds the response). The ideal OS solution for stop trials would be to work with coroutines, but this option is not yet available on OSweb, on which this experiment should ultimately run. So instead, I programmed stop trials by first presenting a sketchpad with the target stimulus, with duration [SSD], followed by a sketchpad of the stop stimulus. As it turns out, the difference between the time stamps of these stimuli is longer than the intended SSD by 8.2 ms (sd 1.3 ms) on average. My questions:

1. Which value gives the best estimate of the real SSD? The intended value or the value calculated from the time stamps?
2. What is the best estimate of the reaction times on stop-signal respond trials? In the current implementation a keyboard response object follows the stop-signal with delay = 0, with the idea to calculate the stop-signal response RT off line by adding SSD and the keyboard response.

I add the OS implementation and my pilot data (Excel last columns) as attachment.

Thanks!

Sander Los

Stop_online_Sander.xlsx

StopTask.osexp

Daniel

Hi Sander, just a short response from me, which resembles the one I gave you in your email, but maybe @sebastiaan can confirm my claims (or the opposite). If you take the time_ variable of a sketchpad item, this actually represents the time that the run() function of this item was called. In this run function the sketchpad contents are drawn to the screen, but this may have to wait until current refresh cycle of your monitor has finished. Thus, this delay (which can amount up to 16ms on a 60Hz monitor) will become apparent if you subtract the time_ variable of the sketchpad item from that of the item that immediately follows it. Even though you thus expect the time difference to be [SSD] , it actually will be [SSD] + 1 to 16ms .

Once the stimulus has been drawn to the screen, OpenSesame will immediately progress to the run() function of the next item with almost no delay, so the time_ variable of this item is more representative of the time at which your stimulus actually appeared on the screen. I hope this makes sense. I admit this still makes it hard to verify the real value of the `SSD` though, and I wouldn't know a way to do this without using an inline_script item in which you set variables to check the timing and draw a canvas (e.g. sketchpad) to the screen.