A common requirement is to synchronize the presentation of a trial with the start of a scan. This document describes two different ways to do so.
Method 1 – Interfacing With the Scanner
This is the preferred method. MRI scanners have the ability to generate a signal just prior to the start of a scan. Once the hardware connection is established, SuperLab can be easily setup to look for the signal.
There are different ways to bring the scanner’s trigger to SuperLab. Much depends on the scanner model and hardware available to you, but the general idea is to make the trigger “look” like a participant input to SuperLab. Examples:
This is by no means comprehensive, as there many different hardware options available, but hopefully it provides some pointers.
Within SuperLab, make sure that the corresponding input device is selected if necessary. For example, if you are using a Lumina, click on the Experiment menu and select Participant Input. A dialog appears showing a list of available input devices; make sure that “Lumina MRI Pads” is checked.
The next thing you need is an event for detecting the scanner’s input. In the Event Editor:
And last but not least, you need to link this event to all your trials. You can create just one event and link it to all the trials.
Method 2 – Software Only Solution
The alternate approach is to use SuperLab 5 only, with no hardware interface to the scanner’s trigger. The key is to use the Trial Pacing option; you can see it by double-clicking on a trial to invoke the Trial Editor, then clicking on the Options tab:
The most important thing to understand about this feature is that it will not provide a “hard stop”, meaning that it will not stop a trial in progress when the specified interval has elapsed. This is best explained with an example.
Let’s assume that the scanner’s TR is 5 seconds. In the Trial Editor’s Options tab, you need to enable the option Present next trial… and set the interval to 5,000 milliseconds.
Then, when setting up your trial, you need to make sure that your trial ends before 5,000 milliseconds; perhaps 150-300 milliseconds depending on how complex the trial is (see section below for an explanation as to why). When trial ends, say after 4,800 milliseconds, SuperLab will then wait the remaining amount of time until 5,000 milliseconds have elapsed since the trial started, and then proceed to start the next trial.
Why Using Time Limits Doesn’t Work Well
A common mistake made by SuperLab users (and the reason why this tech support note was created) is to use time limits in the Event Editor. The logic goes like this: the experiment consists of a 500 millisecond cue, followed by a stimulus with a 2,500 millisecond exposure time. One proceeds to setup the cue’s time limit in the Event Editor, and do the same for the stimulus. The assumption is that the trial should last 3,000 milliseconds; and if the experiment has 50 trials, then it should end exactly after 50 times 3, or 150 seconds.
Alas, the assumption is flawed for one main reason: it’s what we call housekeeping. There is always a little bit of overhead when SuperLab runs as it has to perform several housekeeping chores, e.g.:
Most of these housekeeping chores happen very quickly, but the small amounts of time that they do take accumulates over the duration of the experiment. This makes it difficult to get the overall duration of the experiment exactly right, and consequently some trials will not sync precisely with the start of a scan.
Some users then go with a trial-and-error approach, adjusting the time limits until the overall duration of the experiment is almost correct. But even if the experiment’s duration ends up being exact, there are two other pitfalls that will almost certainly cause the overall duration to change again:
If you still want to pursue the time limits approach, it is imperative that you do so on the same computer that will be used to run the experiment.
Stay in Touch