Reading eyelink data (`.edf`) --> empty annotations

💬 Support & Discussions
1

Hi all, and specifically @scott-huberty!

In my lab, we produce eyelink data files (.edf, using SR Research eyelink eyetrackers). We send markers to the system using code like this:

tk.sendMessage(f"{ord(byte)}")

where tk is the eyelink object, as initialized via the pylink API, and byte is a byte value that we’d also send to the EEG system with which we collect data simultaneously.

(see e.g., https://github.com/sappelhoff/ecomp_experiment/blob/ba583a4a4d33bb6095e3e5f1e9d5af8922f87782/ecomp_experiment/define_ttl.py#L21)

Basically: We are writing a digit as a Message, resembling a “trigger code”.

In the .edf file, this looks like (for an ord(byte) of 23):

MSG	6138485 23

Unfortunately, read_raw_eyelink does not convert these trigger codes to annotations. All trigger codes are summarized under the annotation with description: "". I would expect that the above MSG would instead be registered as an annotation with description "23".

If I manually change my datafile to contain a line like:

MSG	6138485 23thisisit

then I do get an annotation called "23thisisit".

I see that in the MNE-Python eyelink testing data, you have lines like:

MSG	14761538 -14 FIX

and this seems to work, and read an annotation "FIX", rather than "-14 FIX".

I am a bit confused what the -14 does in this case (and where it comes from) → and probably, in my datafiles, the digits are interpreted in the same way as your -14 and then I end up having an empty-string-annotation.

Help would be appreciated!

Cheers!

(mne version = 1.5.1)

2 Likes
2

Hello,

That should be fixed by [MRG] Don't look for an offset in an eyelink message if the message contains only 2 elements by mscheltienne · Pull Request #12003 · mne-tools/mne-python · GitHub
We do the same on our site :wink:

Mathieu

3 Likes
3

Awesome! I’m glad more people are interacting with the mne-eyetracking stuff! Ditto what @mscheltienne , hopefully his bug fix on the dev branch solves your issue. Ping me here if it doesnt!

And FYI on the dev branch after @mscheltienne 's fix, these by default will be read in as "-14 FIX" as you would expect. In that example, the number is Eyelink’s estimation of the difference (in samples) between the listed Event onset (14761538), and the True event onset. So in that case Eyelink estimated that this "FIX" event onset was actually 14 samples before the listed timestamp in the file.

3 Likes