Trigger delays between stimulus presentation and EEG recording

Coding
1

Hi fellow PsychoPyers,

I am currently programming a psychomotor vigilance task in PsychoPy that should be used to study the EEG bases of vigilance. The tasks works perfect and the script successfully sends triggers to the EEG machine everytime a new trial starts. Only problem is a significant delay between the start/stop of a trial and the start/stop triggers sent to the EEG file (at least two seconds). I wonder what may cause the problem.

I have been working with the Coder, adding the following lines:

At the beginning of the experiment:

port = serial.Serial(port='/dev/tty.usbserial-1420',baudrate=9600)

to open the COM port

then under “prepare to start Routine trial”:

port.write(b"T1\r\n")

which sends the start trigger to the EEG,

and finally under “Ending Routing trial”

port.write(b"STOPT1\r\n")

which sends the stop trigger to the EEG.

Any idea why the delay is so long? Lemme know if you need more info from me about this, thanks!
Nick

2

Hi There,

Which direction is the delay in? trigger leading or routine leading? :slight_smile:
Thanks,
Becca

3

We have a similar problem with our systems.
We’ve been testing with BioSemi and BrainProducts EEG systems on Windows 10.

I’ve tested the same setup with a photo sensor before and got good results but now I get a delay that is exactly 1 frame long (the trigger is one frame before the stimulus is acutually drawn on the monitor).
The strange thing is, that the Problem doesn’t always accour, sometimes I get the timings I’ve measured some months ago, which a perfectly fine and the next couple of tests the delay occours again.

Has anyone an idea how to solve this? I’ve really tried a lot of things (GPU settings, Windows scaling, different monitors and PCs,…). I assume it’s due to an Windows update but apparently I have no clue where to search further for the solution.

Kind regards,
Dennis

4

Hi Dennis,

To clarify - the trigger is occurring when you expect it but the visual stimulus is delayed? With no errors about frame dropping?

Thanks,
Becca

5

Hi Becca,

yes, that’s exactly the problem.

This is the delay I normally (and now just sometimes) have when measuring at screen center:

Delay_1
The blue area marks the start and the end (not visible in the pictures) of my trigger.

And this is the delay that now occours most of the time:

Delay_2

So it’s basically the normal delay plus one frame.
And either there is the normal delay or the “plus one frame” delay constant over all trials.

Kind regards,
Dennis

6

OK good testing. Is your experiment made in code? if so are you able to share the lines of code where you send the trigger and show the stimulus?

Thanks,
Becca

7

Yes shure, here’s the code:

from psychopy import core, visual, parallel

trigger = parallel.ParallelPort(address=0xDFF8)
nTrials = 100
winWidth = 1920
winHeight = 1080
nFrame = 5

win = visual.Window(size=[1080, 1920], fullscr=True, screen=2, color=[-1, -1, -1])
rect = visual.Rect(win=win, units="pix", width=100, height=100, fillColor=[1, 1, 1], lineColor=[1, 1, 1])

trigger.setData(254)
core.wait(1)
trigger.setData(0)
core.wait(5)
for thisTrial in range(nTrials):
   rect.autoDraw = True
   win.callOnFlip(trigger.setData, 1)
   for thisFrame in range(nFrame):
       win.flip()
   rect.autoDraw = False
   win.callOnFlip(trigger.setData, 0)
   for thisFrame in range(nFrame):
       win.flip()

core.wait(5)
trigger.setData(255)
core.wait(1)
trigger.setData(0)
core.wait(1)
win.close()

Thanks,
Dennis

8

Could you try replacing this with

win.callOnFlip(rect.setAutoDraw(True))

Thanks!
Becca

9

I’ve already tried that and win.callOnFlip(rect.setAutoDraw, True) adds another frame to the already existing delay.
Even when I send the trigger after win.flip() nothing changes.

Kind regards,
Dennis

10

OK and so that we can check for a frame drop, what happens if you use win.callOnFlip('frameTime', frameClock.getTime()) are the frame intervals as you expect?

Becca

11

Unfortunatly the code snippet doesn’t work, but if I use win.recordFrameIntervals I get M = 0,016714965 s and SD = 0,001088521. So there are a few dropped frames but not too many and I can’t see a pattern which would explain a delay…

Dennis

12

OK wild card - where onscreen is your stimulus being presented and what kind of monitor are you using? There is usually a delay in stimuli presented at the top versus bottom of the screen Can PsychoPy deliver millisecond precision? — PsychoPy v2021.2

13

Yes I know, there should be near to zero delay on top and almost a frame on bottom. So my normal ~7 ms delay in center is fine. But now I have the plus one frame on every position I’ve testet (top left, center center, bottom right).

Right now I’m testing on a normal 60 Hz Samsung Monitor, but the problem also persists in the lab on our ASUS 144 Hz gaming monitor, where we first discovered the delay.

I more and more tend to think it’s Windows update related. Maybe somebody who reads this thread and is also using Win 10 could use my script and test if they are also affected.

My next step will be in switching to Linux on one of the lap PC’s and see if it also happens there, then I will (probably) know if it’s OS related or not.

Maybe @jon can help or bring in some EEG specialists to help. :wink:

14

There are a number of things beyond our control that can cause delays after the rendering leaves our hands, such as operating systems using a frame for “compositing”, graphics cards having delays for triple-buffering, or monitors using time for image optimisation (post-processing). On windows, one that we’ve noticed recently is that window scaling causes windows to switch into a triple-buffered mode and everything gets delayed by a frame. But I’m afraid there are really very many things to check here and I’m increasingly of the opinion that settings triggers with photodiodes is the safer option (because operating systems sometimes forcibly update and suddenly the timing has changed!)