timing issues with PyGaze start and stop recording

yaelholz

Hi,

I'm building an experiment using OpenSesame with PyGaze and EyeLink.
It's important for me that every trial in my experiment will save as a separate reccording (each trial starts with "pygaze start recording" and ends with "pygaze stop reccording"), and of course I want the timing to be precise.

I checked the timing and saw that each trial takes almost 1000 ms more than it supposed to. I think the reasone is that pygaze_start_recording and pygaze_stop_recording take time. I saw that the time between "pygaze_start_recording" and the stimulus (sketchpad) I present is ~300 ms, and the time between "pygaze_stop_recording" and the "pygaze start recording" of the next trial is ~700).

Is ther any way to fix this timing problem?

thanks!!,
Yael

Edwin

Hi Yael,

Would you mind posting a minimal example in which you illustrate this problem? Delays can occur, but often they are in the area of several milliseconds, not 700! I am very curious to learn what is causing the delay in your experiment, and the code would be a great place to start debugging.

Cheers,
Edwin

Jarik

Hi all,

If I may shed some light on this
I ran into a big delay (in dummy vs EyeLink) some time ago and tracked it down to the commit below, but never found/made the time to test/check/report it....

https://github.com/esdalmaijer/PyGaze/pull/16/commits/69640b7362f93cea7541ba96f43795d47c1b981d

Best,
Jarik

Edwin

Thanks, Jarik, that's very helpful! Maybe @sebastiaan can shed some light on this? (The commit was his.)

sebastiaan

These delays are to give the EyeLink some time to breath when going from offline to recording mode, etc. If you look at the examples provided by SR Research, you'll see that they do the same. I don't dare to remove these delays, because doing so may re-introduce problems; you'll see in the commit message that there used to be 'mysterious freezes,' which were resolved by adding these delays.

But does it matter? The timing during the trial is not affected, only the intertrial interval.

eduard

I experiences similar issues. As intertrial interval was critical for my experiments, I instead recorded entire blocks and send only messages to demarcate trials.

yaelholz

Hi again
@Edwin @sebastiaan , Here is an exemple (osexp file and its output xls file). In the xls: yellow=my calculations, red= the main problematic things (and please note to ( ) "note1", "note2", "note3" in the xls file for detailed explanation).
I'll have more than 700 trials (stimului) in my experiment, so 1 more sec for each trial means very long experiment ...

@eduard, Thanks for your advice. My experiment contain more than 130 blocks so I can record each block separately (although this will also add something like 3 minutes to the experiment-this is not so bad.

But- I'm actually not sure what is the best (or correct) way to build this experiment:
record each trial separately OR each/(or more than one) block(s) separately)...

In my analysis I need to compare the amount of fixation (or saccadas) in different blocks (between different blocks).

When recording each trial separately I get an eyelink file with each trial (each stimulus) in a "different line" (or "trial"- this is how the eyelink call it), and when recording each block separately I get an eyelink file with one block in a "different line" (or "trial"-again, this is how the eyelink call it).

If anyone know what is the best way to build it-let me know

Thanks again!
Yael