Diff for "IdentifyingEventsWithTriggers" - Meg Wiki
location: Diff for "IdentifyingEventsWithTriggers"
Differences between revisions 3 and 4
Revision 3 as of 2009-04-20 16:59:28
Size: 5382
Comment:
Revision 4 as of 2009-04-20 17:01:01
Size: 5396
Comment:
Deletions are marked like this. Additions are marked like this.
Line 41: Line 41:
{{{0 0 0 0 0 0 100 100 100 100 100 100}}} {{{
0 0 0 0 0 0 100 100 100 100 100 100
}}}
Line 45: Line 47:
{{{0 0 0 0 0 0 57 100 100 100 100 100}}} {{{
0 0 0 0 0 0 57 100 100 100 100 100
}}}
Line 53: Line 57:
Line 62: Line 67:
Line 63: Line 69:

General information

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

  • STI001 = 20

  • STI002 = 21

  • STI003 = 22

  • STI004 = 23

  • etc.

Participant responses start with STI009 (28) and end with STI0016 (215) 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: /opt/neuromag/meg_pd_1.2/rawchannels.m from the fifaccess toolbox
[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);

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.

Notes for various software programs

SPM

spm_eeg_rdata_FIF

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.

CbuMeg: IdentifyingEventsWithTriggers (last edited 2015-01-21 13:09:47 by MaartenVanCasteren)