If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Timing and verbose mode

January 28th, 2014, 07:37 AM

Hi,

We are using Superlab 4.5 to program a reaction time task (Serial Reaction Time Task). Basically, the task consists in displaying a circular cue at one of four positions on the screen and recording the response of the participant with a response pad (not the Lumina fMRI response pads fro Cedrus). Once the participant presses the correct button, we have a 400ms interstimulus interval and then present the next circular cue at a new position, and so on for 900 stimuli (in about 15min).

We are now integrating this task in an fMRI setting and would like to have an event-related design, with the finger presses as events. This requires synchronizing the recorded finger presses with the fMRI acquisition. We synchronize the beginning of the experiment with the trigger sent by the scanner, but cannot synchronize the beginning of the following trials in the same way, as they depend on the reaction times of the participants.

When I first measured the total duration of the experiment with a stopwatch, it was about 10s longer than by adding up all recorded reaction times and interstimulus intervals. Then – by going through the numerous threads on timing in this forum – I discovered that there was a checkbox to record the cumulative time in a column of the .txt file. When I compare the final cumulative time with the time measured by the stopwatch, they seem to match! Like that, the errors don’t add up along the experiment.

However, I would like to check how much off individual reaction times and interstimulus intervals can be. For that, launching Superlab in verbose mode seems promising, but I don’t know how to do that. I read the posts by Hank on the subject and tried to download his little script, but don’t know how to execute it.

We are using a MacBook Pro (2.66 GHz Intel Core I7) with Mac OS X 10.6.8.

Comment

When you are trying to diagnose or audit the timing, there are two things you can do:

Enable the "Cumulative time" column. This is found under the Experiment menu, Options and Columns to Save.

Insert a single-millisecond ISI as a "timestamp" event that will show up in the output.

An ISI event of 1ms in length (with the "erase screen" setting off) will consume only 1 ms worth of time during the experiment, but it will insert a row in the datafile where you can see the "Cumulative time" (total running time) of the experiment captured at exactly that point.

Comment

I was talking about this with a colleague and we think the requirements seem to be in conflict with one another. You cannot really synchronize the trial with an MRI scanner while the trial is dependent on when the participant responds. We have seen some users do this but the trial ends on a time limit, with the time limit typically shorter than the TR of the scanner.

Comment

Yes, I agree, it is impossible to synchronize the trials with the scanner. However, we just want to know when the events occurred with respect to the fMRI acquisition. The cumulative time option seems to allow to do it without drift, but I would just like to check how much off the individual reaction times (and interstimulus intervals) are.

I tried to insert a 1 ms ISI, but there is no corresponding row in the .txt file. It registers only the responses of the participants (and the triggers from the scanner). The ISI are not registered.
Is there another option I should enable? Or make the ISI another event type (picture? Text?)?
What about the verbose mode? Is it a legend that actually does not exist (anymore)?

Comment

Ok, that works! The trick was to end the ISI "only after a time limit". My mistake was to have it end "immediately after the event is presented".

Also, as I anyway have a 400-ms ISI in my experiment. I can apparently see when this ISI precisely ends with this option, which is great. It that correct?

Interestingly, I seem better off having the ISI at the beginning of each trial (before my actual event) rather than at the end of each trial (after my actual event). In the former case (ISI first), the recorded RT and the one calculated by subtracting consecutive cumulative times perfectly match, whereas in the latter case (ISI last), there is a 20-30ms discrepancy. Any thought on what is the reason or what it means?

Thanks a lot for all the help,
Lionel

Comment

You are correct about seeing when the ISI precisely ends. However, make sure you're not using a time limit for the ISI and a time limit under the Input tab. If this happens both of the times will be added together.

Regarding your second question, be careful when using the "Reset RT Timer" option if you are re-ordering your events. Depending where the event is located within your experiment, having the "Reset RT Timer" checked can lead to different timing outcomes.

Comment

Interestingly, the timer seems to be reset at the end of the ISI (ISI duration, in the stimulus tab), whether or not the "Reset RT Timer" checkbox is checked.

Otherwise, the 20-30ms difference I was observing when switching the order of the ISI and the actual event was indeed due to the "Reset RT Timer" not being checked. With this option checked, I find the same 20-30ms discrepancy (between RT and consecutive cumulative times subtraction) whether the ISI is first or second.
Could it be that this 20-30ms is the time for drawing my stimulus? I think I read somewhere that the timer started once the picture is drawn (for a "Picture" input).