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:
> you can convert the trigger into an event with a value at a specific
> (with many thanks to Masaki Maruyama for these lines)
> ConstSmp = 5;
> trigdiff = [zeros(1, ConstSmp) B(2*ConstSmp+1:end)-B(1:end-
> ...zeros(1, ConstSmp)];
> for i=1:length(cfg.trialdef.eventvalue)
> TrigChange = [0 diff(B)];
> trigsmp = [trigsmp find((TrigChange>0))] & ...
> I guess you will have to adapt the script a little to your personal
> settings to get it to work.
> Hope this helps,
> >> -----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
> >> 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
> >> 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