But is it possible to do it already on the raw file? (I have a trigger delay of 25 msec.)
The reason for this being preferable in my view is that if you do it after having epoched, you effectively include 25 msec of data before the epoch that does not belong to the epoch. Furthermore, you exclude 25 msec of data at the end of the epoch that does belong in the epoch.
I thought there was a function for this on raw data but I can no longer
find it (so I too would be interested to hear what others have to say). But
it should be possible to do this in sort of a hack-ish way by just shifting
the times of the events in the event table. For example:
# Get the event list events = mne.find_events( raw, min_duration = .002 )
# Adjust the trigger latencies
events[:,0] = [ x + 25 for x in events[:,0] ]
Alternatively, I suppose you could just pull out bigger epochs (e.g., 25 ms
longer than you intend) in the beginning, then use evoked.shift_time later,
and make sure to leave off the first 25 ms of the epoch in your plotting
and analysis. But yes, it would be great if there is a cleaner way to do
this.
Hi Lau,
I am not sure I understand what your use case is for shooting the raw time axis.. If you have a 25 ms delay, why not epoch your data with tmin and tmax that are both offset by 25 ms? That way you will include only the appropriate portions of raw data into your epoch..
Hari
Hari Bharadwaj
PhD Candidate, Biomedical Engineering,
Auditory Neuroscience Laboratory
Boston University, Boston, MA 02215
Martinos Center for Biomedical Imaging,
Massachusetts General Hospital
Charlestown, MA 02129
I thought there was a function for this on raw data but I can no longer
find it (so I too would be interested to hear what others have to say).
But it should be possible to do this in sort of a hack-ish way by just
shifting the times of the events in the event table. For example:
# Get the event list events = mne.find_events( raw, min_duration = .002 )
# Adjust the trigger latencies
events[:,0] = [ x + 25 for x in events[:,0] ]
Note that the first column in "events" contains the time in samples, not
milliseconds. So this will be incorrect unless your sampling frequency
is 1kHz. To shift it by 25ms I would use
I use Steve's suggestion with Martin's modification (shifting event
samples) for a while and it works well.
One other related to consider is that it's also a good idea to take into
account any delay or jitter between the trigger and the stimulus or
condition it is designed to represent. For example, both auditory and
visual stimulus delivery can have an associated delay (or usually worse,
jitter) due to software and/or hardware, so it's not a bad idea to get a
handle on that, too.