General information

It is very wise to refer to Triggers in order to help arrange things when you design your experiment in order to avoid some of these problems in analysis.

The STI101 channel sums the inputs from other channels, which encode values in a binary fashion, starting with STI001.

• STI001 = 2⁰ = 1

• STI002 = 2¹ = 2

• STI003 = 2² = 4

• STI004 = 2³ = 8

• etc.

Participant responses start with STI009 (2⁸) and end with STI0016 (2¹⁵) corresponding to two button boxes x 4 responses each = 8 total response possibilities.

Using STI101 by itself for identifying events can be tricky due to overlapping events and participant button presses, which it seems some software packages handle more gracefully than others (see below). What is considered an "event" from this trigger channel depends on several parameters, typically including:

• The value of the trigger
• How long the event lasts
• Whether the event is preceded by a 0 value on the trigger channel

Participant responses

One relatively common scenario is that a participant presses a button before or during an event of interest. For example, if we are interested in a trigger value of 8, this might appear as 520 (512 participant keypress + 8 EPrime trigger). Depending on how the MEG software is configured to identify events, the event with a value of 8 may not be detectable from STI101.

Some MEG analysis packages will let you ignore certain trigger values; if you are ignoring 512, then a 520 would also be seen as an 8.

Another possible approach is to sum the STI channels of interest outside of the analysis package. For example, if all triggers of interest are 9 or less, you would only need the first four channels of parallel port triggers. You could then make a new trigger channel doing something like this:

% Get the raw channel information
% rawchannels is from the fifaccess toolbox
% locally: /opt/neuromag/meg_pd_1.2/rawchannels.m
[B,sf] = rawchannels('myfile.fif', {'STI001' 'STI002' 'STI003''STI004'});
% values in B should be 0 or 5
% for each row, get the values encoded by that channel
for k=1:size(B,1)
   B(k,B(k,:)>0) = 2^(k-1);
end
% add up these channels to get the new trigger channel
sti101_new = sum(B,1);

Yet another alternative is to select your (stimulus) trigger codes from the set of 1,2,4,8,16,32,64,128, and read your stimulus triggers directly from channels STI001 - STI008 respectively (rather than STI101). Each of these channels have a single value of 5 whenever a trigger is "on" (and 0 if "off"), so can be used to simply tag the time of occurrence of a specific condition (and could be recombined as above if wanted). Importantly these channels will not be contaminated by any keypresses that happen to occur at the same time. Note that to do this, you must have the channels STI001-STI008 "activated" in your Neuromag Project Settings file, otherwise they will not be saved to the FIF file.

Not starting from 0

Sometimes at the beginning of a block of MEG data the trigger channel is not set to 0. This may cause problems identifying the first event, if the software assumes each event is preceded by zero. To avoid this some people will explicitly zero out the trigger channel at the beginning of their presentation script.

Intermediate values

Especially if a trigger channel is downsampled or filtered, there may be intermediate values between 0 and the intended trigger. For example, if the trigger is 100, you might expect the trigger channel to read:

0 0 0 0 0 0 100 100 100 100 100 100

But occasionally you might instead see:

0 0 0 0 0 0 57 100 100 100 100 100

It is probably worth looking at a histogram of your trigger channel to see whether any intermediate values exist:

[B,sf] = rawchannels('myfile.fif', {'STI101'});
hist(B)

Danny Mitchell suggests the following to identify these intermediate values and set them to the following value:

[B.data, D.Radc] = rawchannels(Fdata,trig_chan); offending=find(diff(B.data).*circshift(diff(B.data),[1 1])); B.data(offending)=B.data(offending+1); 

Anecdotal evidence suggests intermediate values may be more common with large trigger values.

Other strange triggers

There have been instances in which additional erroneous triggers have been observed. The following is a 'cleaned' trigger channel that has participant keypresses removed. In this experiment, for each trial, there is a beep (trigger = 9), followed by a sentence (trigger = 1,2,3 or 4). In orange box you can see this correct progression. In the magenta box you can see a trial where there is an erroneous 4 trigger before the beep. There is nothing in the EPrime code that should send this. Additionally, if you look at the very first trial (magenta circle) you can see a short 4 trigger similarly ill-positioned, although because this one was shorter it did not get confused for a trial.

Trigger Tricks

There are a couple of tricks to designing the triggers in order to minimize your efforts later in your experiment. I will show you a small example, but there are an almost infinite number of tricks, which can be done with our hardware. Please set this up carefully as this will save both you and your collaborator's mountains of effort later. Let's take a simple example where you have three different stimuli (monkeys, humans, and flies). For this experiment you want to be able to compare these into many different conditions:

monkeys, humans, flies

mammals, insects

non-humans, humans

In order to accomplish this we will use some very clever and simple trigger coding.

humans = 1

flies = 2

monkeys= 3

Because of the earlier mentioned binary nature of the triggers it is easy to separate out each of the earlier comparisons: monkeys, humans, flies mammals, insects non-humans, humans

This can be scaled up to any experiment.

Notes for various software programs

SPM

For SPM5, the CBU-written function /imaging/local/spm/spm5/cbu_updates/spm_eeg_rdata_FIF.m has several options for defining events from triggers.

For SPM8, the FieldTrip function "read_events.m" is now used (see below), but with a small local modification to use the STI101 channel if no STI0?? channels are in the datafile.

MNE

From Dan Wakeman:

When averaging in MNE, it does not look at only the initial transition. MNE accounts for the slope of the trigger line transition (I am not sure of the exact method of this, if you want to know how please ask on the mne mailing list). You can test this by opening the data in mne_browse_raw and running your mouse along the trigger channel in the bottom of the window the value of the trigger channel will show, and it will not give the 128 value it will show the genuine 147 value). You can also observe this using the new event list function in version 2.6.0. This will not be the case if you read the raw data into matlab using MNE, because MNE does not manipulate the values while reading the data in (however for the purposes of averaging it does calculate the values correctly.).

FieldTrip

The usual FieldTrip function for getting triggers is definetrial, often called as part of preprocessing. I (JEP) did not find this to offer enough control. I wrote my own set of functions, and then visually inspect the trigger channel for each block, manually removing any mis-identified events. These trials can then be passed to preprocessing directly using cfg.trl.