EyeTribe & PyGaze Log Timing Accuracy/Precision

tsummer2

I was wondering if anyone knew how accurate the timing was when logging to the EyeTribe file.
I ran some tests myself but I don't know how valid they are.
This is what I ran in an inline script in OpenSesame:
for i in range(100): eyetracker.log('event') clock.sleep(1000)
Here's a histogram of the inter-event intervals:

There seems to be a lot of variance.
Here is a plot of the inter-event interval as a time series (along with some an EEG test as well):

I am concerned about the accuracy of the logging times because I want to analyze pupil diameter before stimulus presentation, and don't want to analyze areas too early/late.

eduard

Hi ,

Maybe this could be useful to you.

Is it?

Eduard

tsummer2

Hey Eduard,

It seems like the only thing I should take into consideration for variable timing would be time between loops, but don't use one. The for loop described above occurs in one inline script in a sequence. So it seems like that shouldn't be a problem.

As I have investigated further, I learned more about the way the time is calculated for the eyetracker log. Within the pytribe.py script, there is the following function for logging messages:

    def log_message(self, message):
        """Logs a message to the logfile, time locked to the most recent
        sample
        """

        # Get the current time.
        t = time.time()
        # Make a string in the specific format that the EyeTribe uses:
        # yyyy-mm-dd HH:MM:SS.000
        ts = '%s.%d' % (time.strftime('%Y-%m-%d %H:%M:%S'), round(t % 1, 3)*1000)

        # Correct the time to EyeTribe time
        if self._clockdiff != None:
            t = int(t*1000 + self._clockdiff)
        else:
            t = ''
        # assemble line
        line = self._separator.join(map(str,[u'MSG', ts, t, safe_decode(message)]))
        # write message
        self._logfile.write(line + u'\n') # to internal buffer

the 'time' for the log file is calculated by adding the clock difference (self._clockdiff) to the time at which the logging function was called.

I made another recording to see if self._clockdiff could be the source of the variation and got this

As you can see, clock diff fluctuates +- 60 milliseconds at 10 milliseconds steps. This is fine and dandy, but if this were the only cause of variation wouldn't the histogram in my post above only have 6 different values??

So since it doesn't seem to be only due to clockdiff, it must be due to some timing variation in the functions called between each time I log a message, OR the EyeTribe is just not recording samples at a consistent rate. I'm not sure if these problems can be solved.

eduard

Hi,

another source of variability is refresh of your screen. In the link I posted above, Sebastiaan recommends always use a stimulus duration that is slightly lower than your desired duration (depending on the refresh rate of your screen), just to make sure that everything arrives in time (and you don't miss your train). Not sure whether this explains your jitter, but it might. Wanna give it a try?

eduard

tsummer2

Sure thing, I will try that next. I guess I was just assuming that the refresh rate of the monitor is only important for timing when a stimulus was being presented. So since I didn't present any stimuli I figured it shouldn't matter. I hope you are right though!

tsummer2

After I ran another experiment, I think you are right.
But I am still getting a jitter... my monitor has a refresh rate of 60Hz, which is one cycle every 16.66666 milliseconds. That means to "catch the train" I would have to use a delay time slightly less than a multiple of 16.666. I tried 83 ms (~4.98 refresh cycles) and things look pretty good. But then I increased the delay to 4983 ms (~298.98 refresh cycles) and my inter event interval distribution is again bimodal. What could I be doing wrong?

sebastiaan

Hi guys,

Here's a few thoughts. And @tsummer2: Congrats on doing such careful testing! Few people bother to do that.

Let me first point out that the sampling rate of the EyeTribe is (at least by default in the non-pro model) 30 Hz, or one frame every 33 ms. You're seeing jitter that is less than one frame interval. So practically speaking it's of little to no importance.

But it's still curious why it isn't just perfect. The code that deals with the EyeTribe logfile (which I believe has been adapted by @Edwin from yet another library) is a bit tricky to understand, but I think the main source of noise is the use of time.time(). On Windows, this function does simply not return millisecond-accurate timestamps. (There may be other sources of noise too, but my guess is that this is the main one.)

Cheers!
Sebastiaan

sebastiaan

Fyi. Here's a very similar discussion, but the reported jitter is much worse—too much to be accounted for by using time.time():

• http://forum.cogsci.nl/index.php?p=/discussion/2581/