Howdy, Stranger!

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

Supported by

wait_for_fixation_start() returns strange things for EyeLink

Hi all,
I have been using the exp.pygaze_eyetracker.sample() function to get the location of the eye and it seems to work well, both with the Advanced dummy (mouse simulation) and with EyeLink 1000. The only issue with it is that if I use default "Uniform coordinates" setting in OpenSesame, I have to correct the coordinates returned by the sample() function like this (for both the dummy and EyeLink):
eyex = eyex - var.width/2
eyey = eyey - var.height/2
Maybe it is possible to fix this somewhere or put it into the documentation? But it's not a big deal, one just needs to be aware of it.

Next I wanted to get the location not just of any gaze position, but of fixation position. So I used the exp.pygaze_eyetracker.wait_for_fixation_start() function, which works well with the advanced dummy (returns a timestamp and a tuple of x and y coordinates, as described in the documentation, and one just needs to adjust them as desribed above). But it does NOT work with EyeLink: it returns a different number of values, and the coordinates are constant and meaningless (-2^15).
Example output from wait_for_fixation_start() for Advanced dummy:
(43009.0, (529, 399))
(43069.0, (526, 400))
(43189.0, (514, 390))
(43239.0, (513, 388))
(43289.0, (513, 387))
(43339.0, (513, 387))

Example output for EyeLink:
(142906.0, 8726187.0, (-32768.0, -32768.0))
(143386.0, 8726667.0, (-32768.0, -32768.0))
(143579.0, 8726859.0, (-32768.0, -32768.0))
(143924.0, 8727205.0, (-32768.0, -32768.0))
(144167.0, 8727447.0, (-32768.0, -32768.0))
(144529.0, 8727809.0, (-32768.0, -32768.0))
(144831.0, 8728111.0, (-32768.0, -32768.0))
This is not influenced by unchecking Uniform coordinates, nor by switching backend to legacy (psycho does not work at all, error Unable to share contexts).

I believe I have the latest SW (OpenSesame 3.1.4, pygaze 0.6.0a21, PyLink The PC runs WinXP and is connected to a dedicated EyeLink computer (where I did not find any settings that could be responsible for this behavior).

Any ideas what could be wrong? Is there a mistake in my setup or in pygaze/pylink/OS? Is there a different way to get a fixation location?


  • I still don't understand what the wait_for_fixation_start() function returns. But I was at least able to (hopefully) overcome my issue and get a location of fixation by simply first detecting fixation using that function and then getting the coordinates using the sample() function:

    unusedOutput = exp.pygaze_eyetracker.wait_for_fixation_start()
    eyex, eyey = exp.pygaze_eyetracker.sample() 
    eyex = eyex - var.width/2
    eyey = eyey - var.height/2

    (By the way, I have read in other forum topics that it is generally unreliable to detect fixation "online", but I need it that way, and it seems to work well.)

  • Hi,

    The number -32768 is used internally by the EyeLink software to indicate missing data. This makes sense, because the SFIX event doesn't have coordinates! Only the EFIX event (end fixation) does. You can see this in the EyeLink data file:

    SFIX R   444531
    EFIX R   444531 450142  5612      935.9   561.9    2714

    So the bug is not the missing data, but that PyGaze and PyLink even return any values to begin with. @Edwin Agreed? Fixation starts should only return timestamps right?

    Bottom line: Getting the coordinates of the first sample, as you're doing now, is ok in principle. Of course, these coordinates may differ slightly from the coordinates as reported at the end of the fixation, which are based on the mean positions during the entire fixation.


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

  • To chime in, you can also try the function eyetracker.wait_for_saccade_end(). Coordinate-wise, it gives you pretty much the same information as wait_for_fixation_start(), plus a little more.


  • That's a good point.

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

  • Thank you guys!

    To help others, could you perhaps please add some notes about these things to the documentation? E.g. that generally the coordinates are not "uniform", that wait_for_fixation_start() (and maybe other functions as well?) returns different numbers of values depending on the selected eye tracker (it makes it more difficult to test the program using the advanced dummy) and that for EyeLink the gazepos value is not meaningful?

    By the way, I love how simple eye tracking is in OpenSesame, esp. compared to some commercial SW that my colleagues use. Thank you for making research easier!


Sign In or Register to comment.