Millisecond Forums » Millisecond Forums » Inquisit 4 » Persistent timing error

RE: Persistent timing error

seandr — Tue, 26 Feb 2013 16:12:03 GMT

James,

Great, and thanks for posting the follow up - this is definitely useful information to share.

In general, both pretrialpause and posttrialpause should be used when consistent timing is required between trials as these given Inquisit a designated window in which to do preparation work at the beginning of the trial and cleanup at the end.

I'll log a bug on our oddball script to include these attributes.

Thanks,
Sean

RE: Persistent timing error

JamesH — Sun, 24 Feb 2013 18:39:08 GMT

Solved.

The problem is the lack of a post-trial pause. If we specify a trialduration for the whole trial, but allocate part of it for what is probably the time that Inquisit uses to dump memory, reallocate, etc. then the timing works out very well. We just ran 40 stimuli @ 1 per second and the TTL signal was millisecond-accurate for all 40.

In other words:

/trialduration = 1000

^^^ reallocation errors

/trialduration = 1000

/posttrialpause = 100

^^^ accurate

Hopefully, this will save anyone using TTL some time in future. Thanks for your help.

JH
Usyd

RE: Persistent timing error

JamesH — Sun, 24 Feb 2013 17:56:39 GMT

I want to make sure I understand the graph - this is presumably showing the TTL value of pin 2 on the parallel port, correct?

No, this is the absolute timing between either 'on' or 'off' signals as per the comments which TTL sends to the ADI box. These signals are 1 second apart and so each point on my graph above represents the time between comments marked at, say 15.016s and 16.016s, which is correct. Or for an error, 30.335s and 31.352s.

When you gathered the data in the graph, were you manually responding in the task, using the monkey, or just running the task without manual or monkey responses? Note that the script will set that particular pin high upon presenting the auditory stimulus and upon receiving a response (e.g., pressing the space bar), so is it possible the second signal represents the response?

I wasn't responding at all, I just left the script. I tried it as well with a modified trial that consisted only of instructions for a) first frame to play sound and sends trigger, then b) trial times out at 1000ms.

Your port definitions above make no difference to the artifact. I have tried a few settings, but nothing seems to make a difference.

I have also changed the latency of the trials in case this was related to the memory. However, even at 10 second (instead of 1 second) intervals, the timing error persists - every 17th TTL comment is 17ms too long as below.

Seeing as this is the same as the monitor refresh rate, I also tried using stimulustimes=0 instead of stimulusframes =1 for the signal - no difference, the error remains.

RE: Persistent timing error

seandr — Fri, 22 Feb 2013 11:02:52 GMT

Hi James,

Thanks for reporting this.

I want to make sure I understand the graph - this is presumably showing the TTL value of pin 2 on the parallel port, correct?

When you gathered the data in the graph, were you manually responding in the task, using the monkey, or just running the task without manual or monkey responses? Note that the script will set that particular pin high upon presenting the auditory stimulus and upon receiving a response (e.g., pressing the space bar), so is it possible the second signal represents the response?

To factor out the response signal, can you try this using the port definitions below and let me know if you still see that artifact? That will help me diagnose what's happening here. Thanks.

/ port = LPT1

/ subport = data

/ items = ("00000001")

</port>

/ port = LPT1

/ subport = data

/ items = ("00000000")

</port>

/ port = LPT1

/ subport = data

/ items = ("00000010")

</port>

Persistent timing error

JamesH — Wed, 20 Feb 2013 22:59:31 GMT

Greetings from the University of Sydney,

I have a timing error with my Inquisit output which I can't solve. The below graphic displays the error: I have recorded (with AD Instruments Powerlab) the comments which are appended by the <port> tag from the Inquisit script. This is the Auditory Oddball task (which can be found on your website), which sends signals that are perfectly evenly spaced @1s each, with each audio presentation.

As you can see, every 17 presentations the timing records a characteristic error (which is a beat of 1001ms and then 1017ms, as you can see on the graph) with only the most occasional other minor errors.

This main error is unrelated to the task changing between presented stimuli - i.e. is unrelated to the trial or block code and is reproducible.

Your thoughts?

all the best,
JH