20 ms Jitter between trigger and pulse (IOPort)

1
Hello everyone,

I am trying to use the IOPort function of Psychtoolbox to record EEG
data. As you can see in the code below, what I am doing is filling the
audio buffer, opening a Parallel Port, sending a trigger (in this case
"1"), playing the audio, and then closing all ports. (And doing this 20
times.)

This works fine when I am recording the EEG, but when I analyze the
data, I see that the time between the trigger and the pulse varies, with
a standard deviation of about 20 ms. Do you have any idea why this might
be? I am fairly new to psychtoolbox so I'm sure the code could be
improved. For instance, am I doing something wrong by filling the audio
buffer every time? Or is it wrong to open the port after filling the
audio buffer? Would it help to reverse the order?

I am asking because when we use a commercial software, this jitter (i.e.
standard deviation) is somewhere around 5 ms, which is acceptable.

The OS running the script is Windows XP, and is installed on a laptop.

Any help would be much appreciated.

Hakan

-------------------------------------------------------------------------
Here's the code I use;

[y, freq, nbits] = wavread('MonoPulse100ms');
wavedataShort = y';
nrchannels = size(wavedataShort,1);
shortPulse = PsychPortAudio('Open', [], [], 3, freq, nrchannels);

i=0
while i<20
trigger=1
PsychPortAudio('FillBuffer', shortPulse, wavedataShort);
myport=IOPort('OpenSerialPort','COM2');
IOPort('Write',myport,char(trigger));
PsychPortAudio('Start', shortPulse, repetitions, 0, 1);
PsychPortAudio('Stop', shortPulse, 1);
IOPort('CloseAll')
i=i+1
end
2
Hi Xiangrui,

Thanks for your reply. If I understood well this RTBox is used to check whether the stimuli generated on a display are correct. For that purpose we have this http://www.gtec.at/Products/Hardware-and-Accessories/g.TRIGbox-Specs-Features in our department. Besides that we do not wish to trigger the EEG with external device we want this to happen internal when stimulation is occuring onscreen, a trigger signal is sent from the PTB to SIMULINK.

Thanks for your help
Norbert
3
> As far as UDP goes, at least our pnet() command for sending UDP is usually low latency enough ( < 1 msec on a properly working local network), so a 20 msec jitter would be very unlikely.

is this really worth encouraging?  no IP protocol has any timing guarantees, and UDP even explicitly doesn't guarantee that any given packet will be transferred!  i know that in practice it is usually OK, but isn't this just silly engineering?  plus, this stuff is susceptible to nagle/buffer config tuning...  
https://groups.yahoo.com/neo/groups/psychtoolbox/conversations/topics/11318

> Third thing is you use Windows, and Windows-7, which is a generally a low performer, even if some people get lucky with some setups and hardware/software combos. Use Linux for sanity.

i've been using ptb on win xp/win 7 for ~10 years, on probably 50 different machines with at least 20 different (usually most inexpensive available) hardware configs (lately even using motherboard integrated or even cpu-based gfx), and never run into any issues.  i almost always precompute stimuli into textures and do a drawtexture for each frame, almost never do i do opengl stuff or use the pipeline, etc., tho i don't have problems when i do that either.  what are the timing problems that you run into that i should be looking out for?  it's not that i don't like linux, it's just that usually the other people in the lab (esp the PI) aren't comfortable with a mixed infrastructure, and often there is equipment that only has a windows interface.  even on my home network i haven't yet figured out how to get a crouton'ed chromebook running ubuntu to see local network shares (my macbook and windows boxes all smb with each other fine).

i just remembered http://www.mathworks.com/help/daq/ref/logtodiskmode.html, which supposedly streams data continuously to disk in another thread.  might make single-process stim/recording reasonably clean, tho i'd definitely monitor it for timing hiccups.  i can't quickly tell from the docs whether that and http://www.mathworks.com/help/daq/ref/transfermode.html are still available in the newer "session-based interface"?
-e
4
> what are the timing problems that you run into that i should be looking out for? 

i should also say i always run single headed, i'm aware linux is required for good timing in dual headed mode, tho it's hard to convince my labmates to care about this.  :)  they run dual headed a lot and tend to argue that the stim display is fine, only the monitoring display tears.  i haven't tested it for them, it's their problem.  but would you say this is expected, mario?

-e
5
Hi Flister and Mario,

Thank you so much for this healthy discussion. Just to make some points clear here:

1) The trigbox is used to sense data from the photodiode and transmit it towards the EEG acquisition unit as an additional EEG channel.. So if I have 6 channels of EEG then at the output I would have 7 channels with the 7th one being the trigger signal from the trigbox.

2) I might have slightly confused you because I have tried two things to send a trigger:
    a) UDP packets -  seems to be working fine apart from the fact that it introduces a random latency which defy its purpose.
    b) Photodiode + triggerbox - where I confirmed that stimuli are precisely generated with PTB.  However, we would like to remove this external trigger and transmit this trigger internally without photodiode and trigbox similar to the UDP approach but without significant latency involved. Is this possible in any way?

3)  The EEG acquisition unit we have in our lab is from g.tec and there are ready made SIMULINK blocks that can be used to configure and extract EEG data. That's why we are using SIMULINK. So, EEG data is transmitted towards an external hardware (in our case an amplifier) which connects to our laptop via USB. The SIMULINK blocks extracts this data and stores it for later processing. The trigger signal is going to tell us when the stimulus was ON and when no stimulus was presented to the subject. Thus, using trigger information we can extract the meaningful data. You can appreciate that having delays in the trigger will result in taking the wrong EEG data for analysis.

@ e_flister
> i say ditch simulink and trigbox, etc.  use data acquisition toolbox on another computer to record either your serial or parallel port stimulus TTLs and photodiode output simultaneous w/eeg.

I think I don't have another option but to use SIMULINK. The trigbox however, we would like to remove it as I have mentioned before. So maybe you're suggesting that one laptop would be use to present the stimuli onscreen and transmit a trigger towards another laptop that is recording both EEG data and trigger input, Is this what you meant by the above? However, this would require an additional laptop which we wouldn't like. If you have any other ideas where the trigger is passed internally rather than external to other hardware or ports that would be great.


@mario
> So you have to untangle which of these causes your huge - even by Windows standards - timin jitter. PTB itself is certainly capable of sub-msec timing for such setups. DirectX or similar wouldn't help you here, as this is definitely not were your problem is.

From literature which I have reviewed, it seems that when researchers require stimuli that vary between themselves in phase, they tend to use DirectX. It is programmed in C++ and I thought that it might give more direct control towards the hardware resources of the laptop then Matlab can.  However, PTB seems to be capable of performing precise timing and the only limitation might be the hardware setup itself.

Thanks once again.

Cheers, 
Norbert