Delay between parallel port trigger and photodiode measured display onset

Other
1

I am testing timing accuracy for display and EEG trigger via parallel port.
I thought that this will be an easy thing because the EEG trigger can be bound to / or send immediately after the win.flip() command, and sending the trigger should occurr in practically no time.
It turned out, however, that i was wrong.

  1. Couriosly, the parallel port signal arrives at the EEG recording maschine actually earlier than the signal for the visual image, which was measured via photoelectrode (using a device calles StimTrack, developed by Brain Products).
  2. The delay between the visual signal and the trigger signal is huge amounting to 18-28 ms (i.e., there is an offset plus some variability). With a CRT Monitor refresh rate of 85 Hz you would probably expect a delay of around 6-8 ms for a stimulus that is presented at screen center, but this is much lower than the observed delay. Furthermore, there should be almost no variability).

The same results can be reproduced using a Matlab script, such that it is probably not the presentation software that is causing the problem

We use a very good computer on which we replaced the onboard graphics with an NVIDIA Quadro K620 (this was a convenience choice, a gaming card might be better). The machine is new and almost unused before. Windows 10 is installed.

I suspect that the StimTrack is introducing both part of the delay and part of the variance, but I am not sure. The support guy suggested a graphics card issue. Any other Ideas?

The code I used is this

from psychopy import core
from psychopy import parallel
from psychopy import visual
win = visual.Window()
rect=visual.Rect(win, width=200, height=200, fillColor='white', units='pix')
def initialize():
    visual.TextStim(win, 'Init').draw()
    win.flip()
    core.wait(1)

initialize()


parallel.setPortAddress(address=0xDFF8)
parallel.setData(0)
for i in range (10):
    rect.draw()
    win.flip()
    parallel.setData(1)
    core.wait(0.1)
    parallel.setData(0)
    core.wait(0.4)
    win.flip()
    core.wait(0.5)
print '...finished'
1 Like
2

Have you tried reading though similar posts already on this forum?

If the signal is somehow arriving “before” the stimulus is displayed, then yes, that likely indicates a problem with time synchronisation, as in the thread above.

3

Try using a different monitor. I’ve seen this sort of problem when using some flat panels where the monitor itself is adding delays!

4

Ahh, yes, that’s something to consider too. I think I’m still locked into thinking that displays all still act like good old simple CRTs.

5

Hi Micheal, thanks for your response:grinning:. I tried to find something but maybe I got the keywords for search wrong. However, it seems that NTP does not really help in my case, because as far as I understand it, parallel port (“LPT”) triggers are not package based. In fact, the trigger does not seem to be the problem, because it is send out immediately after the flip. What is strangely delayed is the picture on the screen, which should appear approximately 7 ms after the flip at the center of the screen (where the photodiode is placed).

6

Hi Jon, thanks for your response :grinning:. We had a flat panel connected at first during all the installations, and used it also for the first test (similar result as I reported). The monitor connected now, however, is a CRT, which is connected to the DVI analogue output via a passive VGA adapter. That’s why I am really puzzled. To my understanding, if the program waits for the vertical retrace signal, and then sends the trigger to the parallel port, there is no way of the parallel port signal being 20-30 ms ahead of the video signals as picked up by the photodiode.

7

And could you just confirm that frame syncs are working? You could check the frame rate using the Coder demo “timeByFrames”.

When you say you get the same issue using matlab, I assume you’re using psychtoolbox but this would also have warned you if there was a problem syncing. It does point to a hardware issue rather than software if neither package is having the expected low latencies.

I’d be surprised if a Quadro K620 were causing problems, but I’d also be a little surprised if this were coming from the StimTracker - surely the latencies in those should be good - timing is the only thing it’s supposed to do?!

Sorry, I’m at a bit of a loss as to what else would cause this

8

This was very helpful, prompting me to look for other possible causes. I checked the timing with timeByFrames, which revealed no problems with frame syncs (no dropped frames). I checked a couple of other things (ethernet plug in versus out), before I finally realized that the window is not fullscreen (shame on me). Now the delay is 6-8 ms, which is as expected.

At least two things seems to be instructive: 1. fullscr=None intruduces quite a lot of delay, much more than I had expected. 2. Things are not always what they seem: The similar problems in Python and Matlab did not point to a common underlying cause, as they actually had different causes (Python problem solved, Matlab problem yet to be solved).

Thanks!

1 Like