Trigger jitter - serial (or parallel) output?
by Omri Perez · in Torque Game Engine · 10/21/2008 (8:48 am) · 8 replies
Hello Everyone,
I'm a phD student and a new owner of a 1.5 TGE and I'm using it for a neuroscience behavioral experiment.
The experiment necessitates that I send out triggers (pulses) from the computer to the recording equipment at certain exact times when significant events in the experiment occur.
So far I have done this using audio triggers through the audio jack. The downside is that relative
to the system time derived by getRealTime() they jitter around 70 ms.
I was wondering whether there was a way to tigthen the timings, like using different threads or some such. a different alternative is to try and output the trigger through a serial or parallel port which
should have less latency, right?
Thanks in advance,
Omri Perez
I'm a phD student and a new owner of a 1.5 TGE and I'm using it for a neuroscience behavioral experiment.
The experiment necessitates that I send out triggers (pulses) from the computer to the recording equipment at certain exact times when significant events in the experiment occur.
So far I have done this using audio triggers through the audio jack. The downside is that relative
to the system time derived by getRealTime() they jitter around 70 ms.
I was wondering whether there was a way to tigthen the timings, like using different threads or some such. a different alternative is to try and output the trigger through a serial or parallel port which
should have less latency, right?
Thanks in advance,
Omri Perez
#2
Ok let's see.
Say I find a c/c++ code that utilizes serial/parallel port. do you think it will be more real time than the audio output. if so how do I incorporate it into the engine.
second is there a way to output audio that is more real time than alxplay()?
lots of questions....
10/23/2008 (4:36 am)
Thanks T Holt.Ok let's see.
Say I find a c/c++ code that utilizes serial/parallel port. do you think it will be more real time than the audio output. if so how do I incorporate it into the engine.
second is there a way to output audio that is more real time than alxplay()?
lots of questions....
#3
just curious,
how have you determined that there's delay between an event happening in the experiment (an event in TGE, i presume ?) and the signal leaving the audio port ?
10/23/2008 (9:55 am)
Omri,just curious,
how have you determined that there's delay between an event happening in the experiment (an event in TGE, i presume ?) and the signal leaving the audio port ?
#4
for each event I save the system time using getRealTime() and then use alxPlay() to play a simple audio trigger.
Afterwards when I look at the recordings of the audio output and the logged system times, I refer to the first event as happening in time zero for both modalities. assuming zero latency and jitter you would assume the 2nd event would happen the same x ms in both modalities after the 1st event. it just so happens that it doesn't. and to varying degress. -20 to +50 ms.
10/23/2008 (2:23 pm)
Let's say in a certain time frame I have 5 such events.for each event I save the system time using getRealTime() and then use alxPlay() to play a simple audio trigger.
Afterwards when I look at the recordings of the audio output and the logged system times, I refer to the first event as happening in time zero for both modalities. assuming zero latency and jitter you would assume the 2nd event would happen the same x ms in both modalities after the 1st event. it just so happens that it doesn't. and to varying degress. -20 to +50 ms.
#5
yes, that sounds like an accurate analysis then.
i hear that USB is also quite easy to work with these days.
the Make Microcontroller is pretty cheap, and can be talked to via USB, Ethernet, or RS232. i think it took me about an afternoon to get mine to turn LEDs on and off. it may introduce more latency, but hopefully wouldn't jitter.
10/23/2008 (6:47 pm)
I see.yes, that sounds like an accurate analysis then.
i hear that USB is also quite easy to work with these days.
the Make Microcontroller is pretty cheap, and can be talked to via USB, Ethernet, or RS232. i think it took me about an afternoon to get mine to turn LEDs on and off. it may introduce more latency, but hopefully wouldn't jitter.
#6
I have an inclination to use the parallel port, all though some of the laptops involved don't have one.
I was thinking of using an adapter such as this.
in such a case how would I implement a simple call to it (all i need is an all or nothing output signal) ?
thanks in advance,
Omri
10/25/2008 (10:28 am)
Thanks Orion,I have an inclination to use the parallel port, all though some of the laptops involved don't have one.
I was thinking of using an adapter such as this.
in such a case how would I implement a simple call to it (all i need is an all or nothing output signal) ?
thanks in advance,
Omri
#7
but this is an urgent matter.
Could someone guide or point me to a guide on how to incorporate simple usb,serial or parallel
output into the engine?
THANKS:)
10/29/2008 (6:14 am)
Sorry for posting repeatedly,but this is an urgent matter.
Could someone guide or point me to a guide on how to incorporate simple usb,serial or parallel
output into the engine?
THANKS:)
#8
libusb seems like a reasonable one to look at.
google also seems to have a number of interesting results around "writing to the serial port windows".
10/29/2008 (8:31 am)
Have you googled for USB libraries ?libusb seems like a reasonable one to look at.
google also seems to have a number of interesting results around "writing to the serial port windows".
Torque Owner Tim.Holt