[visionegg] Re: visionegg for fMRI experiments

It occurs to me that there may be another issue when dealing with MRIs 
(not specific to the Vision Egg): As you know, both the MRI machine and 
the video card have their own internal (and very constant) cycle times. 
  I foresee a potential problem if, for example, the MRI pulse triggers 
your visual stimulus application, which may get the pulse quite quickly 
(within 1-2 msec, I'd guess), but then it's some unknown time (maximum 
one vertical retrace interval) between then and when the video card 
actually draws a new frame.  Perhaps this isn't actually an issue: is 
the inter-frame interval of sufficient precision for the temporal 
alignment of the stimulus and the MRI device?  If not, you could 
investigate some of the higher-end workstation graphics cards with a 
video sync input ("genlock").

If this is a potential problem, I would suggest trying your stimuli 
with "synchronize buffer swaps" (vertical retrace lock) off.  In this 
way you would run the loop as quickly as possible: for simple visual 
stimuli, 1000s of frames per second.

On Wednesday, November 27, 2002, at 08:42  PM, Pallier Christophe wrote:
> On Tue, 26 Nov 2002, Christoph Lehmann wrote:
>> Thanks for your help. Concerning the parallel port: We built a
>> TTL-streching circuit (flip flop) which enlarges the with of the TTL
>> pulse to e.g. 50ms. Is it that what you mean with the potential 
>> problem:
>> that TTL per se are too short to get recognized by the parallel port?
>> So, do you think a low to high and back to low step, lasting for 50ms
>> would be enough for your parallel port code?
>
> I also need to trigger stimuli from TTL sent by a MRI scanner (on my
> system, the pulse lasts 5 msecs though).

If your video frame rate is 200 Hz or faster (and no frames were 
skipped), you wouldn't miss these even if "synchronize buffer swaps" 
was on.  Otherwise, turn it off, and make sure your inter-frame 
intervals for drawing the frames (what the VisionEgg.log file reports) 
never exceeds 5 msec.

> To check the latency on my linux system, I used latencytest
> (http://www.gardena.net/benno/linux/audio/).
>
> On a Dell Cpx 650Mhz PentiumIII notebook with an ATI Rage Pro...,
> the worst latency was... about 200ms! (on a 2.2.16 kernel, not patched
> with the low latency patch).
>
> The latencytest puts a lots of stress on the system, so in a real
> situation the worst case may not happen frequently.
>
> Also the situation may be better with more modern hardware,
> but I advise you to try latencytest, and apply the lowlatency patches 
> to
> your kernel if necessary.

I haven't kept up with linux much as of late because I found that the 
Vision Egg was never skipping frames at 200 Hz under Windows 2000 Pro 
(as long as the stimuli weren't too complex) and I have stuck with that 
for now.  If I remember correctly, the latest kernels are much better 
with respect to latency and don't need patches (and the 2.2.16 kernel 
is quite old).  I would be interested to hear reports of frame skipping 
(or not) under the recent linux kernels.

> Another point:
> The timing of a MRI scanner is perfectly stable, many experiments just
> need to synchronize with the very first pulse of a sequence. This may
> simplify the programmation a lot...

Yes, this seems like a reasonable way to go.

Cheers!
Andrew

======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: