[open] Several issues when using OpenSesame portable with an Eyelink 1000

gerardo

I'm opening this thread to report a series of issues I've found when using OpenSesame portable 2.8.1 and 0.27.3 to run eye tracking experiments using an Eyelink 1000 v4.51. I thought that opening a different thread for each of them would clot the board, but if you prefer it, just let me know.

OS port. 0.27.3 with eyelink plugin:

• For some reason, when performing "drift correct", the test requires two fixations to be performed, instead of one. The first fixation works as it should: a button being available at the host pc for manual validation, the degrees of deviation being shown after the fixation is achieved. After it, instead of the next part of the experiment being run, the fixation point remains onscreen until a new fixation is done. For this fixation, the only buttons available are "Calibration" and "Validation", so you cannot manually accept it. After the second fixation is achieved, no info on accuracy is displayed.

• If at any moment during the experiment you interrupt it to go to the camera setup screen or the calibration screen, it is impossible to continue with the experiment from where you stopped. The test screen stays blank or showing a fixation cross, but the drift correct process is not executed. Therefore, is not possible to interrupt an ongoing experiment to recalibrate the eye tracker.

• As I stated in a previous post, the set_backdrop instruction doesn't seem to be working with my configuration. But I have just realized that, in order to avoid the experiment crashing, I had to remove line 898 from libeyelink.py, as it was negating the preceding if statement:

if hasattr(el,"bitmap2DBackdrop"):
    send_backdrop = el.bitmap2DBackdrop
else:
    send_backdrop = el.bitmapBackdrop
send_backdrop = el.bitmap2DBackdrop

It might be that the reason send_backdrop is not working is related to this.

OS port. 2.8.1 with pygaze plugin:

• When a running experiment gets aborted or throws an exception, the connection with the eye tracker doesn't fully close, and the program kind of freezes, displaying a greyed out GUI that doesn't allow you to perform any action. Still, you can close it and save the experiment when prompted. I think what's going on here has to do with the transferring of the edf file. The debug window is the only thing that remains active, showing ´libeyelink.libeyelink.close(): Closing data file
  libeyelink.libeyelink.close(): Transfering file.edf to C:/Dir/file.edf´. I've found that, in these case, a edf file is created in the host pc, but not in the experimental one. Also, while OS 0.27.3, which doesn't display this behaviour, saves the file to the OS directory, OS 2.8.1 saves them to the directory where the log file is being saved.

• Also, the cmd window that the batch file launches doesn't close automatically after exiting OS port 2.8.1. I don't know if it is relevant, but it might be a hint of what's going on

• On the other hand, drift correct works as it should, and it is possible to pause the test to recalibrate and restart from the last point. I have not been able to test the backdrop function as I could not find documentation about it and the program sort os freezes, as described, every time it throws an exception. I'm just assuming that the backdrop functionality is implemente in the pygaze plugin, but it might be that it's not the case.

martinc

Hi,

we have an experiment running on an Eyelink 1000 with 2.8.1 and have the same symptoms (freeze/ .edf file doesn't copy to display machine). I found some discussion between Sebastiaan and the SR developers over on the SR forums, which suggested a solution was in the works. Has there been any progress on this?

sebastiaan

Hi @martinc and @gerardo,

PyGaze is now the focus of development, so if you encounter problems with the EyeLink plug-ins (which won't be fixed), I would switch to PyGaze.

The main issue until recently was, as you experienced, the transfer of the EDF file, which caused the application to freeze (see issue #14). This should be fixed if you grab the latest snapshot from my fork (Edwin hasn't merged these changes yet).

• https://github.com/smathot/pygaze

I'm just assuming that the backdrop functionality is implemente in the pygaze plugin, but it might be that it's not the case.

Actually no, that functionality hasn't made it into PyGaze. I'm not sure whether that was a conscious decision, or whether it is because this functionality was added after PyGaze had already been forked off the EyeLink plug-ins. At any rate, for now you could consider using PyLink (the EyeLink Python wrapper) directly to handle the backdrop. You can see how this is handled here:

• https://github.com/smathot/opensesame_eyelink_plugins/blob/master/eyelink_calibrate/libeyelink.py#L807

Please let us know about any trouble you encounter with PyGaze. It's still under heavy development, but the idea is that this will be the central place for eye-tracker functionality in OpenSesame.

Cheers!
Sebastiaan

martinc

Hi, should have made it clear that we were using pygaze. Thanks, @sebastiaan, for the pointer to your fork -- will test!

martinc

To follow up: The forked pygaze works much better -- we now have .edf files on the display computer, thanks! Viewing the camera image on the display computer is now very slow -- much slower than in the previous version (although it shows slightly more information). We can obviously run like this, but if anyone has any clues as to what might be causing the bottleneck...?

sebastiaan

Viewing the camera image on the display computer is now very slow -- much slower than in the previous version (although it shows slightly more information). We can obviously run like this, but if anyone has any clues as to what might be causing the bottleneck...?

The camera image processing was extra slow due to the additional information. That, and the fact that the camera image is handled in a way that works for all back-ends (upside), but is terribly inefficient (downside). It's purely visual though, you will not get any lag during tracking.

I just commit a few updates again. You could try those, and see if you like it better.

Question: I occasionally experience freezes when recording is started for the first time. Do you experience that as well? (It might be Linux-specific) I explained the issue in more detail on the SR Support forum:

• https://www.sr-support.com/showthread.php?4106-pylink-beginRealTimeMode()-freezes-and-some-other-issues-(Ubuntu-14-04-64-bit)&highlight=opensesame

martinc

Hi Sebastiaan, sorry for the silence, and thanks for the updated plugin. We're mid-experiment so I can't change the software until the end of the run; will test as soon as possible after that.

I haven't come across any freezes running on WinXP (but will check with my students!). I can also have a go at running on linux if it would help you -- only problem is that the systems I have to hand are 64-bit, does this matter?

--M

sebastiaan

Hi Martin,

I haven't come across any freezes running on WinXP (but will check with my students!).

Good, I suspected as much, i.e. that it would be Linux specific.

I can also have a go at running on linux if it would help you -- only problem is that the systems I have to hand are 64-bit, does this matter?

Any testing would be helpful, but if you're a Windows user then I wouldn't worry about switching to Linux just for this purpose. Especially because I'm in the process of switching our lab machine to Linux, so I will test Linux more (and Windows less). 64 bit is no problem, btw.

Thanks for thinking along!

Cheers!
Sebastiaan

martinc

Windows user? How dare you? Mostly Arch Linux, but in the lab we also use Experiment Builder/DMdX from time to time (hopefully less often as OpenSesame matures!), hence Windows. I'll test on Linux when I get the chance.

sebastiaan

Windows user? How dare you?

Ow yes, right ...

• https://aur.archlinux.org/packages/opensesame/

  b-(