| Reference | Downloads | Github

Screen refresh delay in sending parallel port response triggers

OS (e.g. Win10): Win10
PsychoPy version (e.g. 1.84.x): 3.1.0
Standard Standalone? (y/n) If not then what?: Y

What are you trying to achieve?:
I am trying to send parallel port triggers exactly as the response buttons are pressed.
I have used a builder component with the following set up:

When the parallel port component is positioned before the keyboard component, the delay between the response time in the output file and the parallel port trigger is about 13 ms which equates to 2 frames.

When the parallel port component is positioned after the keyboard component. the delay is about 6.7 ms which equates to 1 frame.

What did you try to make it work?:
I have looked at a previous thread:

It suggests to remove the following parts of code in relation to the parallel port component:


Originally my coder view script looked like this:

What specifically went wrong when you tried that?:

I removed the callOnFlip commands and run the task again (from the coder view) but the delay was still there.

This was the code:

        # *p_port_prac1b* updates
        if (prac_resp.keys == 'm' or prac_resp.keys == 'c' or prac_resp.status == FINISHED) and p_port_prac1b.status == NOT_STARTED:
            # keep track of start time/frame for later
            p_port_prac1b.tStart = t  # not accounting for scr refresh
            p_port_prac1b.frameNStart = frameN  # exact frame index
            win.timeOnFlip(p_port_prac1b, 'tStartRefresh')  # time at next scr refresh
            p_port_prac1b.status = STARTED

        if p_port_prac1b.status == STARTED and t >= (p_port_prac1b.tStart + 0.05):
            # keep track of stop time/frame for later
            p_port_prac1b.tStop = t  # not accounting for scr refresh
            p_port_prac1b.frameNStop = frameN  # exact frame index
            win.timeOnFlip(p_port_prac1b, 'tStopRefresh')  # time at next scr refresh
            p_port_prac1b.status = FINISHED

I also unticked the option Sync to screen in the builder component, but again, the delay persisted.
In the tab Data there is another option called Sync timing with screen refresh which I had ticked. When I unticked it, the trigger timings were completely bizarre and not related to responses.

Should I change something else in the code? Or is there a way to fix this within the builder component?


Heey, I am still struggling with this. Any advice for how I can fix the delay?
Much appreciated!
@dvbridges @jon

Hi @MartaT, the positioning in the routine does count. If you have your pport before the keyboard, and a response is made, the pport does not know this until the next screen refresh (or the next iteration of the routine loop). Then, if you have the sync to screen refresh set for the pport, the trigger is sent at the end of that current frame (1 screen refresh). If you have the pport positioned after the keyboard, and the pport is not synced to the screen refresh (so it triggers as soon as a keypress is registered and the pport keypress condition is satisfied), is the timing any better?

Hi @dvbridges!
So I have been playing around with this again today and I literally tried most of possible combinations of the position of the pport and the keyboard, and the different sync to screen options.

The most successful coordination of these two components happened when I unticked all of the sync to screen options for both the pport and the keyboard. When the pport was positioned before the keyboard, the first delay was 2 frames and all other trials had a delay of 1 frame.
I moved the pport component back to the very bottom (after the keyboard) with the same setting of no sync to screen options. The first delay was just slightly less than one frame and all other delays are between 0.3 - 1 ms.

This is a much better result and I can take this into account when analysing the EEG data. But I was wondering whether you think it would be possible to send the signal precisely at the button press or whether I should give up now. (I can use the output file to manually mark on the EEG output when the responses happened exactly, although it would be more helpful to have the pport signal).


That effectively is exactly at the time the button is (recorded as being) pressed. i.e. this is far more precise than the timing of the keypress itself. If you are using a regular computer keyboard, it could typically have a lag of say, 30 ms, and a variability of say 15 ms. In that context, 0.3 - 1 ms is no time at all. If this level of precision is necessary, you should look at using dedicated response hardware rather than a standard keyboard.

@Michael this clarifies it for me, thanks a lot!