Hi,

usually if the file is not broken (and this shouldn't be the case), the output should be very much the same: both Brainstorm and filedtrip use the MNE(-matlab)  toolbox to open .fif files, so I don't expect big differences ... Are you using the latest version of both toolboxes, i.e.  the very same version of the underlying men-matlab toolbox? 

What I see (now) from your post on the mailing list is that first you load the events like this

events = ft_read_events(file);

and then you pass these events to ft_definetrial. 

This is not usually the way to use it, since in the "events" variable you'll have many more events than what you are really looking for (since beyond 'STI101', all the events on the other STI* active will pop up). 

Try to dry run ft_definetrials with 

cfg.trialdef.eventtype = '?'

and then load only the ones that you need., and check again the examples on the wiki pages. I wouldn't be surprised that fiedltrip gets puzzled by the too many events in "events" ...

My 2 cents ....

Thank you so much for your answer.  I will try this.  However, the key problem is that when the data is read in it begins at say sample 40,000 rather than 1.

Just because I'm tinkering with fieldtrip right now :-) ...

Check quickly with ft_read_header(file) and see what the:

hdr.orig.raw.first_samp

says. It could well be that for some reason you clicked "Record raw" on your acquisition console e.g. 40 s after the "Go" click for some reason, and this is the starting point for your data. In the data that I've now this  is something like 8000 samples, and I'm not worried since I spent probably 8 seconds scrolling through the data before recoding the data to the disk. Maybe Brainstorm puts some more intelligence/magic here, but the number of samples in Brainstorm, in

hdr.nSamples (assuming hdr=ft_read_header(file))

and 

hdr.orig.raw.last_samp - hdr.orig.raw.first_samp

should be the same, maybe minus one sample.

The ones in the orig structure are directly copied from mne_whatever.m, so assuming that mne is the ground truth and reads what is in the .fif header, the rest is just passed over the higher level functions ...

It's a quick check, and if you find the answer, please update your own post on the mailing list, for the sake of the community ...

Thanks for this (and sorry for the delay).

I'm just now checking the hdr.orig.raw variable, and this states that the first sample is 10500 and the last is 452999 (giving me a total of roughly 348000).  I'm still struggling to understand why Brainstorm loads the full data (452999 samples) and Fieldtrip does not. This is a concern because I am losing event information contained in the first 10499 samples.

Having triple checked this it actually turns out that the same issue is occurring in Brainstorm, so I'm thinking that this is an acquisition problem.  Exactly what though I am unsure.  Thank you for your help.

Hi,

as said and expected the underlying functions devoted to the .fif reading should be the same in both toolboxes.

 If you want to dig deeper, take a look on how the example file 

mne_ex_read_raw

uses

fiff_setup_read_raw

So, if i do this now on a random fif file on my computer, I get

info = fiff_setup_read_raw(fileName)

the output  is:

Opening raw data file blahblah.fif...

Read a total of 13 projection items:

generated with autossp-1.0.1 (1 x 306) idle

[13 times repeated] ...

Range : 16000 ... 654999 = 16.000 ... 654.999 secs

Ready.

info =

fid: -1

info: [1x1 struct]

first_samp: 16000

last_samp: 654999

cals: [1x467 double]

rawdir: [1x639 struct]

proj: []

comp: []

As you can see, the first sample in my measurement is 16000 and the last is 654999, but I'm neither surprised nor worried of this behaviour: this happens just because, in this particular acquisition file, between the "Go" button press and the "Record raw" ticking passed exactly 16 seconds. In this 16 seconds very likely someone just checked the HPI, and scrolled through the MEG channels to take a look, and then pressed "Record raw". These same numbers you will get as well if you use elekta's very own "show_fiff" utility on the acquisition console. This is a "finnish peculiarity", dunno otherwise how to call the fact that in the final file they start counting from 16000 instead of 0 ... 

So, my take is that you had 10 seconds (at 1 kHz sampling) before ticking the "Record raw" check box. *But* if you say that you have missing conditions/trials/triggers in your final list, then the only answer that I have is that someone started the stimulation paradigm *before* ticking the "record raw": once in a while happens also to me with young students . Don't put the blame on the analysis software, or on the acquisition, go back in the lab and slap someone randomly ... :-)

HTH