Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Synchronization problem Opensesame + EyeTribe

edited December 2016 in PyGaze

Dear Community,
I am using Opensesame + EyeTribe eye tracker. I am having trouble to sincronize the recording (self.recording and self.stop_recording) with the time at the trial level; for instance, a trial with opensesame last 3000 ms, and I am recording EyeTribe samples along this trial. However, when and I sum all the durations of the samples (each about 16 ms) they do not add up to 3000 ms; rather I get sums of between 1500 and 2500 ms.
Anyone has any suggestions?

Many thanks in advance,
Guido

Comments

  • Hi Guido,

    Could you upload your experiment and the datafile?

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • Hi Guido,

    You'll have to be a bit more specific. I can see in the experiment that you have a 3000 ms delay between calling eyetracker.start_recording() and eyetracker.stop_recording(), at least if display_offset is 3000 and post_view is 0. So I get that point.

    But what do you mean by this?

    However, when and I sum all the durations of the samples (each about 16 ms) they do not add up to 3000 ms; rather I get sums of between 1500 and 2500 ms.

    Can you illustrate exactly what you do here, and how you arrive at the values between 1500 and 2500? For example by uploading a datafile and describing what you do with that. And what makes you think that the sample duration is 16 ms?

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • When I look at the log file, I find that the time difference between star_recoding and end_recording is aproxx 1500 and 2500 ms, instead of 3000 ms,
    The 16 ms are for the frequency of the tracker (60hz), within the log file appears sampletime: 16.67 ms.
    I apologize I'm new to this, maybe my code is wrong.
    What I need to do is for the log file to record 3000 ms of recordings, but for some reason I get different time trials in the log file.
    thanks you.
    guido

  • Hi Guido,

    This is puzzling indeed. There's threading involved, which always introduces some jitter. But this seems a bit much, even for Python threading.

    Here's what I would try:

    for i in range(10):
            eyetracker.log('T%d = %s' % (i, clock.time()))
            clock.sleep(3000)
    

    This will give you messages in the EyeTribe log file like this:

    MSG 2016-11-16 10:20:42.570 759950922   T1 = 373892
    # lots of samples
    MSG 2016-11-16 10:20:45.570 759953922   T2 = 376892
    # etc.
    

    So the first two timestamps are given by the EyeTribe. The last one (T1 = ...) is given by OpenSesame. What happens if you do this? Do all timestamps agree on how much time has passed? If not, then which of the following do you see:

    • OpenSesame reports something else than 3000 ms between each message (it absolutely shouldn't).
    • The EyeTribe reports various intervals between each message, but on average it's 3000 ms (i.e. there's a lot of noise)
    • The EyeTribe reports various intervals between each message, and they are on average:
      - Less than 3000 ms (the EyeTribe thinks that time runs too fast)
      - More than 3000 ms (the EyeTribe thinks that time runs too slow)

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • Guido,

    I have noticed a similar problem in my own experiments. At one point, I did essentially what Sebastian suggested above but I used a sleep time of 5000ms. I measured the time between my logged events, and took the difference between them to get the inter-event interval (IEI). For every experiment I ran, the beginning of each recording had shorter IEIs than what it was supposed to be. Below is a histogram of IEIs of the first 100 samples of my EyeTribe (30Hz sampling rate).

    You can see that the majority of the samples are actually shorter than 5000ms, which is the same problem you were having. Here is the same data but plotted as a time series

    As you can see, the first 24 samples are shorter than what they were supposed to be. This means the first 10seconds or so of recording will most likely be a little off. The good news is that the IEI gradually moves towards where it is supposed to be.
    I have no idea why this happens. The only suggestion I can make is for you to make one long recording (only one start and stop). Start the recording early, have at least 10 seconds or so before you actually start presenting stimuli to avoid this weird effect, and log events to indicate trials.

    -Ted

  • edited January 2017

    Hello all.
    We have similar timing issues as Guido. Basically, we are running pygaze on a python 2.7.3 on Windows 10 with an EyeTribe eyetracker. We observed a similar difference between the time measured with pygaze.clock (or pygame.time) and the eye tracker. When looking into the validation (of calibration) data we observed that the pattern of eye movements followed the correct timing but the messages (logs) showed to be faster or compressed, and consistently the recording also ends before the indicated time (stop_recording).

    After running code similar to the one Sebastiaan suggested we obtained the following output:

    MSG 2017-01-25 23:43:50.945 413688353 start_recording
    MSG 2017-01-25 23:43:53.209 413690617 T0 = 7436
    MSG 2017-01-25 23:43:54.275 413691683 T1 = 10495
    MSG 2017-01-25 23:43:55.290 413692698 T2 = 13563
    MSG 2017-01-25 23:43:56.256 413693664 T3 = 16599
    MSG 2017-01-25 23:43:57.205 413694613 T4 = 19651
    MSG 2017-01-25 23:43:58.137 413695545 T5 = 22848
    MSG 2017-01-25 23:43:59.136 413696544 T6 = 25941
    MSG 2017-01-25 23:44:00.085 413697493 T7 = 29061
    MSG 2017-01-25 23:44:01.018 413698426 T8 = 32105
    MSG 2017-01-25 23:44:01.867 413699275 T9 = 35174
    MSG 2017-01-25 23:44:02.749 413700157 stop_recording
    

    Where we observed that the pygame timing is correct, but the eyetribe timing is not.

    You can see the code here users.df.uba.ar/juank/eyetracker/experiment.rar

    Any help or suggestion is welcome.

    Agustin

  • Hi guys,

    I just tested my own Eye Tribe, and (fortunately) I don't experience the problem. I attached the full data file and experiment. Basically, I let a fixation dot jump from left to right and back, three times with a 2000 ms delay. With every displacement I logged the X coordinate and timestamp. You see that OpenSesame and the Eye Tribe perfectly agree, both indicating 2000 ms between each message:

    MSG 2017-01-26 16:08:51.668 458389065   TARGET 812 TIME 23805
    MSG 2017-01-26 16:08:53.673 458391069   TARGET 212 TIME 25810
    MSG 2017-01-26 16:08:55.680 458393081   TARGET 812 TIME 27816
    MSG 2017-01-26 16:08:57.684 458395060   TARGET 212 TIME 29820
    MSG 2017-01-26 16:08:59.691 458397066   TARGET 812 TIME 31826
    

    If I plot eye position, it's also clearly accurate, in the sense that my gaze shifts when you would expect it to shift after each displacement.

    So that's good.

    But this raises the question: Why is synchronization off for you, but not for me? What versions of the relevant software are you using exactly? My test was done with:

    • Windows 7 professional
    • Python 2.7
    • OpenSesame 3.1.5a5
    • PyGaze 0.6.0a21

    The Eye Tribe server reports the following:

    @Edwin Do you know where the timestamps in the data file come from? Do they come from the Eye Tribe (along with the gaze data), or from PyGaze?

    Cheers,
    Sebastiaan

    There's much bigger issues in the world, I know. But I first have to take care of the world I know.
    cogsci.nl/smathot

  • Thanks @sebastiaan ,

    My system is:

    Windows 10 Home 64bit
    Python 2.7.3
    Pygaze 0.5.0 (Downloaded Dec-2016, not sure how to check version... I look into the init.py file)
    Pygame 1.2.14

    Best,

    agustin

    PS: currently downloading opensesame for checking with your script, thanks

Sign In or Register to comment.