Do EyelinkDoDriftCorrection and ApplyDriftCorr perform drift correction or drift check with Eyelink 1000?

Hello,

I’m looking into data that I collected using Psychtoolbox version 3.0.15 (maybe 3.0.14) combined with an Eyelink 1000. The data has been collected in MATLAB 2015B.
I was wondering if the drift correction functions actually perform a drift correction or a drift check. In the former case, the values of the calibration map are shifted, but in the latter case, the calibration values are just reported (although the output still reports DRIFTCORRECT, see this post from SR-Research).
SR Research notes on their website [LINK] that for Eyelink 1000 systems

the default behavior in the Pupil-CR mode in these systems is to simply report the calculated fixation error without altering the calibration map

However, I can’t recover how Psychtoolbox has implemented this.
My code looks something like this:

            temp = EyelinkDoDriftCorrect(el);
            Eyelink('ApplyDriftCorr')

el contains some values about size and colour, as well as the command to display the calibration results and to skip target beeps. The other values are default values coming from EyelinkInitDefaults.

So my question is about the behaviour of these commands. Do EyelinkDoDriftCorrection and ApplyDriftCorr follow the default drift check behaviour as noted by SR-Research, or are they applying an explicit drift correction with a shift of the calibration map?

Thank you in advance for your explanation!

Edit: I think I found the answer in this post. Unless you send driftcorrect_cr_disable = off to the Eyelink or explicitly enable Drift Correction on the host PC, there’s only a drift check without a correction.

These are thin wrappers around the Eyelink C runtime functions eyelink_apply_driftcorr(), eyelink_driftcorr_start(), and do_drift_correct(). Nothing magic Psychtoolbox specific happens here.

EyelinkDoDriftCorrect by default calls Eyelink C runtime function do_drift_correct().
Eyelink('ApplyDriftCorr') calls eyelink_apply_driftcorr().
If you’d use EyelinkDoDriftCorrect with el.callback set to the non-default value of [] ie. empty, then it would call eyelink_driftcorr_start() instead.

The function has not changed since 2010, see:

Therefore it’s likely that it simply follows/followed Eyelink default behaviour, whatever that is for any given Eyelink model.

-mario

1 Like