Millisecond Forums

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 oddballsignal>

/ port = LPT1

/ subport = data

/ items = ("00000001")

</port>

<port baselinesignal>

/ port = LPT1

/ subport = data

/ items = ("00000000")

</port>

<port responsesignal>

/ port = LPT1

/ subport = data

/ items = ("00000010")

</port>

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.

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 

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