Synchronizing Trial Presentation With fMRI Scanner

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.

Hardware Interface

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:

The easiest ways is via our Lumina fMRI response pads. The Lumina 3G controller has built-in inputs to accept scanner triggers. For GE scanners, you need a custom-built cable. For Siemens scanners, you need a fiber optic cable. Both kinds are available from Cedrus. If you have the older LSC-400B controller and using it with Siemens, you need a small adapter device that converts Siemens’ fiber optic signal to an electrical one; this may still be available from Cedrus.
SuperLab for Windows supports input from a Measurement Computing I/O device. The scanner’s trigger can be connected to one of the device’s input.
Some customers have shared with us that they purchased one of our RB Series response pads and had a technician open the response pad and wire the scanner’s trigger in parallel with one of the key switches. This voids the warranty but keeps costs down.
Other customers have used the same approach with a standard computer keyboard.

This is by no means comprehensive, as there many different hardware options available, but hopefully it provides some pointers.

SuperLab Setup

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:

Click on the Input tab.
Check the option After a correct response from the participant.
Now click on the Correct Response tab.
In upper right corner, click on the popup menu and select “One or more of the following:”.
Check the response that represents the scanner’s trigger. For example, if using Lumina, check “Scanner Trigger”. If using an I/O card, check the input line that the trigger was wired to.

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.:

Allocating and freeing memory for stimuli
Loading stimuli from disk to memory
Decompressing pictures prior to a trial’s start so that they are presented very quickly
Presenting stimuli, i.e. the time it takes to draw on the screen
Keep track of collected data
Other miscellaneous tasks

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:

Changing computers, e.g. developing the experiment on one computer and running it on another
Altering the computer, e.g. replacing a hard disk or adding RAM

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.

Back to SuperLab Support main page

Last Revision: February 10, 2016

Support ‣ SuperLab ‣ Synchronizing Trial Presentation With fMRI Scanner

Method 1 – Interfacing With the Scanner

Method 2 – Software Only Solution

Why Using Time Limits Doesn’t Work Well