negative onsetdelay& log with prerelease

[liwenna]

Hello Karl,


I certainly am no genius at this but here are some thoughts

1) the negative onsets are generally not more worrying than the
positive ones, do aim at getting them as short as possible. I never
built an fMRI task, not sure how precisely timed you should aim with
them. I'd guess that less than 20 ms would be quite acceptable? But
here's some explanation: The onset time depends on your display's
refresh rate. In your logfile's you should find a pretty exact (not
sure how accurate though!) measurement of the refreshrate, made by e-
prime, somehow...? :s  (perhaps someone else may shed some light on
that?) It may read 75.352 for instance... but let's say that that
simply is a 75 hertz refreshrate. What is a 75 hz refreshrate...? For
displays that are not too intelligent (i.e. old type crt screens) each
pixel of the display will be "replaced" 75 times per second... the
display will continually refresh pixels starting at the topleft pixel,
moving in rows to the right then the next line until the bottomright
pixel is replaced and then starts again at the top left pxiel. Most
LCD displays have some built in intelligence that will decide for
itself when to replace pixels, although there are more modern LCD
displays that apparently do have a more predictable pixel refresh
pattern. In any case: This kinda means that a pixel can only be
replaced once every 13,3333 ms.... (75 refreshes per 1000 ms ->
1000/75 = 13.33333). So.. if your fixation period is set to last 3000
ms (for instance), e-prime will try to make it last 225,00
refreshrates... which should actually be ok most of the time... but
you wrote that your fixation periods are varying... say that you also
have trials in which it is 2500 ms? Then e-prime would try to make it
last 187,50 refreshrates... which is impossible and therefore in half
these trials the timing will be off by roughly half a refreshrate in
one direction (+6 or +7) and the other half of the time by roughly
half a refreshrate in the other direction (-6 or -7).

2) yes it does that... wiht prerelease you tell e-prime to start
working on the next slide while the current one is still up, this
interferese with it's ability to log responses to this slide. But I
actually don't think you should use prerelease on the pic.... because
there is no accurate timing needed for the NEXT slide, is there?
Moreover: the next slide is on the next run of the trialprocedure,
right? (next fixation period)... not sure about this but I don't think
prereleasing works 'over to the next run of the procedure', although
it may be possible if you use a certain scrip.

3) Sorry, I don't understand your question here :/

What it boils down too: to get really precise timing you often need a
whole constellation of tricks and one of them is to adjust your
desired display durations to the refresh rate of your screen and then
also actually use a screen that is predictable in it's refresh rates.
But I kinda reckon that in your mri room you will have LCD's or that
you'll want to use that laptop? Moreover you'll likely have a whole
projector set-up for showing the display to the participant in the
scanner. All of these will add to imprecise timing,

I have no idea how bad that is for an fMRI type experiment... I'd
reckon that, given that fMRI has a temporal resolution of a few
seconds itself (right?), you have no need to be worried about 20ms
delay... but do consult with someone more knowledgeable on fMRI and e-
prime ^.^

best,

liw


On Apr 14, 12:20 am, Karl <jie.liu.ps... at gmail.com> wrote:
> Hello, all
>
> We just got a new laptop (win7) and installed the eprime
> (professional2.0). Our fmri paradigm is relatively simple--every trial
> has two components: 1) a fixation period with duration varying from
> 2000 to 4000ms 2) a pic presentation for 2000ms during which a
> response of button pressing is collected.
>
> 1) We tried to prerelease the pic, but whatever the prerelease number
> is, there are still lots of non-zeros in the pic-onsetdelay log file.
> They are generally less than 20ms, but more concerning is that there
> is even negative onset delay, like -5 or -11. What could the problem
> be?
>
> 2) if we set the pre-release too long, it seems to disrupt logging the
> response we collect during pic presentation. For our case, should we
> use prelease of pic or not? If not, how can we still ensure pic onset
> is accurate? Chapter 3 is quite unclear about this.
>
> 3) It is suggested here to use cumulative timing code for fMRI. Just
> curious about shorting the stimulus presentation duration is less
> concerning in fMRI?
>
> Thanks in advance
>
> Karl

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.