On behalf of Filip van Opstal:
>
> hi Olaf,
>
> I don't know about a hardware solution, but in the case you're
> analyzing your data with the Fieldtrip software package you can easily
> solve the problem by adding a few lines in the 'trialfun_general'
> script (or whatever file you're calling in the cfg structure to
> extract the events from the raw fif-file).
>
> So after extracting raw channel data from the fif file:
>
> [B,SF,T0]=rawchannels(cfg.dataset,cfg.trialdef.channel);
>
> you can convert the trigger into an event with a value at a specific
> sample:
> (with many thanks to Masaki Maruyama for these lines)
>
> ConstSmp = 5;
> trigdiff = [zeros(1, ConstSmp) B(2*ConstSmp+1:end)-B(1:end-
> 2*ConstSmp)...
> ...zeros(1, ConstSmp)];
> trigdiff(find(trigdiff<0.5))=0;
> trigsmp=[];
> for i=1:length(cfg.trialdef.eventvalue)
> TrigChange = [0 diff(B)];
> TrigChange(find(TrigChange<cfg.trialdef.eventvalue(i)/2))=0;
> trigsmp = [trigsmp find((TrigChange>0))] & ...
> ...(bitand(trigdiff,cfg.trialdef.eventvalue(i))))];
> unique(trigsmp)
> end
>
> I guess you will have to adapt the script a little to your personal
> settings to get it to work.
> Hope this helps,
>
> Filip
>
>
>
>
> >> -----Message d'origine-----
> >> De : Announcement for the Neuro MEG list
> [mailto:[log in to unmask]]
> >> De la part de Olaf Hauk
> >> Envoyé : mercredi 17 juin 2009 14:10
> >> À : [log in to unmask]
> >> Objet : problems with trigger sampling
> >>
> >> Hi,
> >>
> >> we have recently become aware of a problem with trigger sampling in the
> >> Neuromag system. Externally delivered trigger values are not always
> read
> >> correctly at the beginning or the end of a trigger pulse (both in the
> >> digital trigger channels as well as the combined channel STI101). The
> >> first and last sample point may show an intermediate value between 0
> and
> >> the actual trigger value (e.g. ...0 0 240 255 255... instead of ...0 0
> >> 255 255 255...). We tested sampling rates of 1000Hz and 5000Hz, and it
> >> appears that there is always a delay of exactly one sampling point (but
> >> more erroneous triggers occurred for the 5000Hz case). We therefore
> >> conclude that the problem must lie on the acquisition (rather than the
> >> presentation) side.
> >> Has anyone else come across this problem before, and possibly found a
> >> (hardware) solution? Not every analysis software automatically handles
> >> this problem correctly, and it has already caused some confusion in the
> >> Cambridge MEG community.
> >>
> >> Regards,
> >>
> >> Olaf Hauk
> >
>
>
|