Dear Panagiotis,
Yes, there is a perfectly sensible explanation for all of that. What
you are dealing with is a continuous file with 'pseudo-trials'. CTF
can either acquire files as truly continuous (so that the whole file
is one trial). Then, for instance, it allocates the space on the disc
for that file in advance and if you stop the acquisition in the middle
the rest of the file will contain zeros. Also if your acq crashes, no
usable data will be saved. Alternatively you can configure your system
to work in pseudo-trials (lets say 1 sec long). Their borders usually
are not related to your events of interest but just to the start of
the acquision. It's exactly for that kind of case that 'read across
trial boundaries' option exists and in your case the answer should be
'yes'.
When you epoch the data what the CTF software probably does is gets
rid of those pseudo-trials first and epochs the data in your true
trials - hence the results you observe.
One thing that you should pay attention to is that after you say 'yes'
there are no discontinuous jumps in your data. In CTF there are 3
options for how to handle the pseudo-trials and for some of them the
data in each of them is baseline-corrected which is not so good for
you. If that happens, you need to run CTF newDs command to stitch your
pseudo-trials back into continuous file again. If you need some help
with that let me know. I happen to have the same issues with my own
data.
Best,
Vladimir
On Thu, Nov 19, 2009 at 4:03 PM, Panagiotis Tsiatsis
<[log in to unmask]> wrote:
>
> Hello dear all,
>
> I am facing the following problem:
>
> I am using the convert command from the SPM interface to read a continuus CTF meg data file and to isolate its parts of interest. Therefore, I am selecting "Define Settings:" -> Yes, "How to read?" -> Trials, "Where to look for trials?" -> define, "Start.." -> -200, "End.." -> 500, "How many conditions?" 6, and then I have to select my triggers from a list, which is:
>
> Type: Tr1 ; Value: ; 47 instances
> Type: Tr2 ; Value: ; 50 instances
> Type: Tr3 ; Value: ; 42 instances
> Type: Tr4 ; Value: ; 51 instances
> Type: UDIO001_down ; Value: 5 ; 7 instances
> Type: UDIO001_down ; Value: 6 ; 7 instances
> Type: UDIO001_down ; Value: 7 ; 28 instances
> Type: UDIO001_down ; Value: 8 ; 24 instances
> Type: UDIO001_down ; Value: 9 ; 12 instances
> Type: UDIO001_down ; Value: 10 ; 14 instances
> Type: UDIO001_up ; Value: 5 ; 7 instances
> Type: UDIO001_up ; Value: 6 ; 7 instances
> Type: UDIO001_up ; Value: 7 ; 28 instances
> Type: UDIO001_up ; Value: 8 ; 24 instances
> Type: UDIO001_up ; Value: 9 ; 12 instances
> Type: UDIO001_up ; Value: 10 ; 14 instances
> Type: trial ; Value: ; 257 instances
>
> From there I select my (known) triggers to be
>
> Type: UDIO001_up ; Value: 5 ; 7 instances
> Type: UDIO001_up ; Value: 6 ; 7 instances
> Type: UDIO001_up ; Value: 7 ; 28 instances
> Type: UDIO001_up ; Value: 8 ; 24 instances
> Type: UDIO001_up ; Value: 9 ; 12 instances
> Type: UDIO001_up ; Value: 10 ; 14 instances
>
> as these correspond to my rising edge of my event triggers.
>
> When I review the individual trials, everything looks fine, that is the event order and the timings match the data that I have from the program producing the stimuli.
>
> Now, the crucial part is the question "Read across trial borders?" From what I understand, and since I could not find any detailed explanations in the SPM manual, the trial borders should be defined as the "start" and "end" time of the trials that are characterized by the triggers of the 6 events that I have explicitly defined. Note that my trials are always at least 4 seconds apart (you can also verify that by the SPM trial file that I have attached).
>
> Now when I select "No" in the option "Read across trials" to assure that I am not including overlapping trials and then select "all" for the channels to be read, I am getting the following error message:
>
>
> SPM8: spm_eeg_convert_ui (v3059) 16:22:02 - 19/11/2009
> ========================================================================
>
> SPM8: spm_eeg_definetrial (v2902) 16:26:35 - 19/11/2009
> ----------------------------------------------------------------
>
> SPM8: spm_eeg_channelselection (v2866) 16:43:34 - 19/11/2009
> ========================================================================
> ??? Error using ==> read_data at 530
> requested data segment extends over a discontinuous trial boundary
>
> Error in ==> fileio_read_data at 11
> [varargout{1:nargout}] = funhandle(varargin{:});
>
> Error in ==> spm_eeg_convert at 360
> dat = fileio_read_data(S.dataset,'header', hdr, 'begsample', trl(i, 1), 'endsample', trl(i, 2),...
>
> Error in ==> spm_eeg_convert_ui at 89
> D = spm_eeg_convert(S);
>
> ??? Error while evaluating uicontrol Callback
>
>
>
>
> So I cannot understand how it is possible that "requested data segment extends over a discontinuous trial boundary" when I am reading a continuus file where the trials are certainly sufficiently further apart. Note that the error remains even if a set really smallo numbers for the start and end of trial, i.e. Start->0, End - >10, it just appears later on in the reading process of the file.
>
> Funilly enough, when I try to repeat the process in the already segmented to trials file produced by the CTF software (**.ds, without the AUX suffix) with exactly the same settings and I select "No" to read across trials, everything seems to work just fine!! The difference between the two cases, is that for the already segmented .ds file, I am getting the following conditions list:
>
> Type: Tr1 ; Value: ; 47 instances
> Type: Tr2 ; Value: ; 49 instances
> Type: Tr3 ; Value: ; 42 instances
> Type: Tr4 ; Value: ; 50 instances
> Type: UDIO001_down ; Value: 5 ; 7 instances
> Type: UDIO001_down ; Value: 6 ; 7 instances
> Type: UDIO001_down ; Value: 7 ; 28 instances
> Type: UDIO001_down ; Value: 8 ; 24 instances
> Type: UDIO001_down ; Value: 9 ; 12 instances
> Type: UDIO001_down ; Value: 10 ; 14 instances
> Type: UDIO001_up ; Value: 5 ; 7 instances
> Type: UDIO001_up ; Value: 6 ; 7 instances
> Type: UDIO001_up ; Value: 7 ; 28 instances
> Type: UDIO001_up ; Value: 8 ; 24 instances
> Type: UDIO001_up ; Value: 9 ; 12 instances
> Type: UDIO001_up ; Value: 10 ; 14 instances
> Type: trial ; Value: ; 92 instances
>
> As you might notice, although the numbers of instances for the UDIO001_up triggers agree, there is a significant difference in the number of "trial" events: this is now 92 (which is exactly the number of trials that I have, 7+7+28+24+12+14 = 92", whereas before, for the continuus dataset, this was 257, which I have no clue where it came from... (note that there is also a difference in the values for Tr2 and Tr4.. this is also puzzling me)
>
> Any intuitions about the whole issue would be really appreciated as I 've been puzzled and I cannot find a full explanation by my self. I am also attaching the events and timings file for the continuus AUX file so that you can see that I am not violating the trial borders by the trial start and end times that I have selected.
>
> Thank you in advance and all the best,
> Panagiotis
>
|