Timing drift vs. missed keystrokes?

[Ignacio Valdes]

I think I have my problem figured out. It has to do with the screen
refresh rate. It discusses this in Chapter 3 'Critical Timing' of the
Users Guide. Our 500 msec stimulus does not match the 13.33333msec
refresh rate of the monitor so it makes it last longer. As stated in
the manual, there is a calculation you can perform to estimate what is
a good stim display rate for your monitor. What is apparently optimal
for our test bed is 496 msec but will vary per machine.

Per your question on whether pre-release makes it miss button presses,
you have to have someone sit with the subject and actually count the
button presses and see that they match what is recorded in order to
notice missed button presses. You can also do a thought experiment
based upon the Pre-Release discussion of Chapter 3 in the User's
Guide.

-- IV

On Tue, 05 Apr 2005 10:36:22 -0500
  Jordan Bigio <j-bigio at northwestern.edu> wrote:
> I have some long pre-releases, but have never noticed that it
>affects the RT (or when e-prime registers the button press). How
>would you notice something like that?? We've run so many Ss that it
>almost doesn't matter now, but I'm curious.
>
> Jordan
>
> At 10:16 PM 4/4/2005 -0400, David Hairston wrote:
>>I have had to deal wit ha similar issue, as the perceptual effect we
>>are currently using w/ fMRI requires very precise timing.
>>
>>I've found that if you are carefull, and you find the source of the
>>timing drift, then you can run with PreRelease set at 0 and have
>>consistent timing every time. For teh amount of time and error oyu
>>describe, one likely culprit is differences in the requested length
>>of stimuli and what is actually possible given the refresh rate of
>>the monitor. That is, you may find that on occasion your stimuli are
>>lasting just a hair longer b/c they have to wait to finish a screen
>>refresh.... this can add up over the course of 10 minutes. Just a
>>thought. Check to see if you have a consistent delay somplace and
>>start there....
>>
>>Good luck.
>>
>>
>>
>>
>>
>>
>>
>>Hello all,
>>
>>I have a paradigm which flashes numbers sequentially in a n-back
>>fashion and the user is supposed to click if there is a match. Each
>>number flashes for 500 msecs with 500 msecs blank in between. There
>>are some filler filler number trials that also last 500 msec with 500
>>msec blank screen. In all, there are 84 trials/Block, with a 10
>>second
>>rest in between for 6 blocks that is then repeated once. Total time
>>for the paradigm is 10:34.
>>
>>There is a problem with timing drift throughout the paradigm if
>>Pre-release is set to zero. The timing drifts about 5 seconds
>>throughout the paradigm so that the last 5 trials do not get
>>displayed. So somehow the trials are slightly longer than they should
>>be. To fix this, Pre-release must be increased to at least 9 msec for
>>the number display and 9 msec for the blank screen in between. AFter
>>doing this, it no longer drifts and stops at the correct moment.
>>However, this impacts keystroke recording as in: it doesn't record
>>keystrokes reliably. This is grossly apparent at Pre-releases of 100
>>msec or more. I'm testing this at 9msecs x 2 = 18msec to see how many
>>keystrokes it misses. This leaves a possible 0.018 sec window of time
>>in which a subject response may be missed. E-prime support has been
>>notified of this last week and they are working the problem, so far
>>with no success.
>>
>>In a nutshell, increase pre-release fixes timing drift problem and
>>introduces keystroke recording problem. Decrease pre-release to zero
>>fixes keystroke recording problem but introduces timing drift
>>problem.
>>
>>Has anyone encountered this or have a solution?
>>
>>-- IV
>
> Jordan D. Bigio, B.A.
> Project Coordinator
> Developmental Cognitive Neuroscience Laboratory
> Department of Communication Sciences and Disorders
> Northwestern University
> 2240 N. Campus Dr., Frances Searle Building, Rm. 2-342
> Evanston, IL 60208
> Phone: 847-491-3647
>