Eyetracker Troubleshooting

Conversations with Marcus regarding issues with ExperimentBuilder and other aspects of eyetracking experiments

How to know from the message report if any message happened during a particular fixation?

there is a time that the button got pressed which I can get from the message report, but i'm wondering if there's a way to include two columns in the fixrep that say a) what (if any) message happened during that fixation, and b) at what time there was a message if there was one. -EB

Hi Elika,

No worries — it’s actually a bit complicated to try to determine the timing events using message variables in Fixation Reports, so I’m glad you asked. (After you read the discussion below, you’ll probably see why I wanted to code things like the RT variable you mentioned in Experiment Builder rather than trying to get this information from messages).

Note, another way to get the timing of particular events is to set a Reaction Time Definition in Data Viewer — for more information on this, please see the section of the Data Viewer User Manual (Help -> Contents) “Data Analysis and Output -> Reaction Time Definitions”.

Again, in general, if there is a time point that you are interested in, then I would recommend creating variables like the RT one so that you already have this information available in the Reports (the VARIABLES of the EB project will become columns that are available in any of the reports as long as you have them selected as EyeLink DV Variables at the top-most level of the Structure Panel).

That being said, you can still get timing information from messages in things like Fixation Reports, but note that there are three important considerations here:

1) Consideration 1

The time that you get from the CURRENT_MSG_TIME is going to be the trial time. The trial starts whenever the recording of data starts. After Experiment Builder starts recording it waits for a small amount of time (usually around 50 msec, but this is variable) before allowing anything to happen (e.g., before allowing a DISPLAY_SCREEN action to change the screen). So, if you want the time to be relative to a certain event (like the DISPLAY_IMAGES action), then you will need set the interest period and then do a little calculation. Include the following variables:

CURRENT_MSG_TIME TRIAL_START_TIME IP_START_TIME

Then, in a stats program, compute a new variable whose value is

CURRENT_MSG_TIME - (IP_START_TIME - TRIAL_START_TIME)

This will give you the time of the message relative to the start of the interest period.

In general, you always want to make sure to set an interest period (for the reasons given above regarding the delay between the start of recording and the first trial event). To set the Interest Period so that you only see the eye movement data for the period when a particular image was on the screen (which will make it so that you also see the image that the subject saw) you can do the following:

1) Go to the top-right part of the screen and click the drop down menu beside where it says Full Trial Period. Then click Edit. 2) When the Interest Period Manager appears click the New button. Then give it a label (e.g., ImagePeriod) and select Type -> Message. 3) Go to the Details tab. For Start Time Message Text enter the Message that is sent out for the DISPLAY_SCREEN action in your Experiment Builder project that handled the presentation of the image (e.g., DISPLAY_IMAGE; it's case-sensitive so keep that in mind). Then for the End Time Message Text enter the message that is sent out for the subsequent DISPLAY_SCREEN action (e.g.., DISPLAY_BLANK; it's case sensitive). 4) Close the Interest Period Manager.

You should now only be seeing the data for the part of the trial in which the subject saw the image in the reports you create and you will also only see that data (and corresponding image) in the various views of Data Viewer.

For more information about using interest periods in Data Viewer, please see the section of the User Manual (Help -> Contents) "Data Analysis and Output -> Interest Period".

One consideration when creating interest periods is spanned fixations. A spanned fixation is a fixation that starts before the interest period starts and ends after the interest period starts or a fixation that starts before the interest period ends and ends after the interest period ends.

By default Data Viewer includes these fixations (and their total durations for duration-based variables) in reports, but you may want to exclude them (or if you want to include the durations of these fixation as well, then you might want to trim them).

To change the settings related to how Data Viewer handles spanned fixations for an Interest Period you can go to the Preferences Tab of the Inspector. Then below you can click on the Data Filters section. There are two properties below:

Hide Spanned Events -- If checked this will not include fixations that start before an interest period starts and end after the interest period starts and fixations that start before the interest period ends and end after the interest period ends.

Trim Spanned Fixation Times -- If checked this will trim the portion of fixations that are outside of the Interest Period. For example, if a fixation starts at time 200 and ends at time 500 and the Interest Period starts at time 300, then the fixation duration will be reported as 200 msec if this option is checked and 300 msec if this option is unchecked.

Note, you can set the trimming/hiding of spanned fixations independently for the beginning and the end of the interest period if you are using the latest version of Data Viewer: https://www.sr-support.com/showthread.php?4434-EyeLink-Data-Viewer

2) Consideration 2

Another consideration with the CURRENT_FIX_MSG variables is that you could potentially have multiple messages occurring within a single fixation. So, you might want to go to the Output/Analysis section of the Preferences Tab of the Inspector and change the Maximum Messages Variables for Eye Events. This will make a separate set of columns for each of the multiple messages.

3) Consideration 3

The message that you are interested in might have occurred not during a fixation but during a saccade. For this reason, you should also include the variables NEXT_SAC_MSG_TEXT and NEXT_SAC_MSG_TIME (and/or PREVIOUS_SAC_MSG_TEXT and PREVIOUS_SAC_MSG_TIME).

I hope this helps, but please let me know if you have any further questions.

Thanks,

Marcus

'RT' variable

I'm taking a look at some of our data and am a little confused about one of the output vars. there's a variable called 'RT' that gets written for every trial and i'm just not sure what it maps onto. WHen i look in the edf it's not the same as any of the message times. What I thought it would be was the el_button_crit_word time, but it's not. Can you explain to me what that variable is tracking? I'm attachingt he project and a sample edf so you can take a look. -EB

Hi Elika,

The RT variable is the amount of time that has elapsed from the onset of the images in the DISPLAY_IMAGES action to the press of the button on the button box. It is set by the SET_VARS action in the EXP_RECORDING sequence. To see how it is set you can click on the Attribute Value List property for that node.

I hope this helps, but please let me know if you have any further questions.

Thanks,

Marcus

n.b. In short--time 0 is NOT the time the images appear on the screen (which is when the DISPLAY_IMAGES variable gets written into the message report). Rather, it's the start of when the eyetracker is recording your subject's eyeposition, regardless of whether anything is on the screen. Given that we generally zero to the target noun onset, this isn't a huge deal for us, BUT it probably explains some of the weird pre-target-onset behavior we've seen in some studies. have a look below, and think about whether you'll need to adjust your analysis pipeline--or experiment--accordingly. -EB

Brief noise pollution from another audio file.

The attention getter sound in at least one experiment (a harp noise) has a weird artifact of about a half second of an attention getter noise from another experiment (a bird call). Neither the source file nor the audio file in the library has the latter — they sound (and look) exactly as expected. The node in Experiment Builder points to the correct file (the harp noise). The second file, the bird noise, is not used anywhere else in this experiment, and has a different filename. This seems potentially related to an issue that our lab manager, Hallie, raised earlier with popping noises that weren’t in the relevant files. Is it possible that EB is caching these noises somewhere when compiling the experiment? -SM

Hi Stephan,

I think everything is actually fine and working as programmed -- the issue is just that the project is set up to present two different audio files upon onset of the attention getter video. This is because in Experiment Builder there are two ways to present audio: 1) By using a Play Sound action after a Display Screen action) or 2) Checking Synchronize Audio for a Display Screen action (note, this second option can only be done if using an ASIO sound card on Windows or on if on Mac OS X):

The solution here is just to uncheck Synchronize Audio for the DISPLAY_A_G action.

Also, please note that generally in Experiment Builder, the audio presentation and the video presentation for video files used in Display Screen actions is handled separately/independently.

This allows for you to do things like audio/video mismatches experiments more easily. So, after unchecking the Synchronize Audio property of the DISPLAY_A_G action, please then make sure to edit the Sound File property of the PLAY_A_G_SOUND action so that it matches the file you want to be used in conjunction with the ref1.xvd video file. I think doing all that above should resolve the issue.

I hope this helps, but please let me know if that doesn't resolve the issue or if you have any other questions.

Thanks,

Marcus

Where can the audio file for the "duh duh duh (3duh)" track loss noise be found? It is not located with the other media assets.

We are in the process of bringing the audio levels of all of our experiments into closer agreement with one another. One sound that we would like to be able to check the average intensity of the waveform is the track loss noise (we affectionately call it “duh duh duh”, or “3duh”). But it seems like this is not kept with the other media assets… can you clarify where we might be able to find it? -SM

In terms of the duh duh duh sound -- I think you're referring to the Remote warnings, which are configurable in the EyeLink section of the Devices Tab of the Structure Panel:

If these are set to DEFAULT then Experiment Builder generates the sound, and there isn't an audio file being used. Note, though, that you can change those properties to use audio files in your project's Library (Edit -> Library Manager), so you can use your own if you need a more controlled sound.

Why is my experiment repeating trials infinitely, even over the trial counter?

For any conditional tiggers (ie., the ones leading to repeat the trial at end of experiment), make sure the "conditions met/TRUE" condition connection is on the right and the "conditions not met/FALSE" condition connection is on the left. See Lilli's correspondence here:

"I'm setting up an infant eyetracking study. I want the experimenter to have the option to press a key at any point during the trial and have the current trial be repeated either immediately (by pressing [i]) or at the end of the block (by pressing [e]). This way if infants are wiggly or fussy or otherwise distracted, we have a chance to get the same data.

I have this set up in the experimental trial portion of the attached experiment by setting a keyboard trigger for each option that sets a variable. At the very end of the trial, I have two conditional triggers that check the value of those variables and should​ recycle the data line, or not. The variables are then reset at the beginning of the next trial.

This structure seems to work correctly for repeating the trial immediately, as well as for other keyboard triggers like playing an attention getter or recalibrating in the middle of the experiment.

However, it seems that every single trial triggers the recycle-at-end action, no matter if a key was pressed at all during the experiment or not. The experiment never stops. The trial counter reaches the max # of intended trials for that order, and then continues ad infinitum with trials 17/16, 18/16, etc.

I also tried placing the conditional triggers higher in the structure, at the trial level with the attention getter and recalibration checks, but those end up repeating the trial that comes after the one the keypress occurs in. Finally, I also thought of putting the repeat-at-end action immediately following the keyboard trigger at every stage of the trial, rather than setting a variable and checking once, but it seems to me that the number of times you press the key would then affect the number of times the line is recycled, and I know that during infant eyetracking, we're in high speed mode and tend to hit the keys several times in succession.

I have a suspicion that something's wrong with the timing of resetting my variables to 0, but I can't fathom where else in the sequence to do that. I also don't know why only one of the keypress triggers is malfunctioning. Do you mind taking a look and seeing if there's something I've missed?"

Hi Lilli,

The final conditional in the EXP_RECORDING sequence, CHECK_RECYCLE_END, has the recycle node attached to its false/left-hand/conditions-not-met side, so if the recycle at end key was never pressed, the trial will recycle. Please rearrange the recycle and null action nodes for that conditional to remedy the situation, or instead of changing the connections, change the conditional to check for a value of 0 (indicating the recycle at end key was not pressed, so the existing layout would be appropriate).

If I press a key to trigger the attention getter or a trial recycle, the trial lasts longer. It seems like the trial timer restarts from the point of my button press. What should I fix?

"I've attached my experiment. During the experiment recording phase, I want the sequence of events for each trial to proceed as follows:

new trial- beep-2.5 second pre sentence period-play sentence-5 second postsentence period- trial end

and ideally i would be able to press any of my keyboard triggers to change my variables during any of those phases, but it would not change the timing. As the experiment is currently coded, if I press a keyboard trigger during the postsentence period, the 5 second timer restarts from the most recent keyboard press. I also tried connecting the timer trigger node as the "requirement true" side of the CHECK_SENTENCE_OVER node and then to the null action point of the last layer of keyboard triggers, but the same thing happens. Do you have any advice about where to place this node so there's always a 5 second post sentence period?"

Hi Lilli,

The issue is because a timer trigger with its Start Time property set to 0 simply takes the start time of the last action node before getting to the trigger. This time resets if the action is re-entered. So since your keyboard triggers all loop directly back to the same null action node that is connected to the timer trigger, the timer trigger is simply resetting its start time each time. Assuming the 5 seconds duration is meant to begin once the sentence is finished playing, the easiest way to get past this is likely to add a second null action node in line before the existing one. With this added, the flow would go conditional trigger, null action, null action, keyboard/timer triggers. The timer trigger's Start Time property should then reference the time property of the null action directly connected to the conditional (not the one connected to the timer/keyboard triggers). See image below:

Error starting an experiment: can't connect to IP 100.1.1.1

Check that the two ends of the blue cable are connected to the correct ethernet ports:

  • On the Dispaly computer - to the port marked as "Eyelink ethernet".

  • On the Host computer - to the port marked as "Display PC ethernet".

Refer to these to posts on the SR Research Forum (h/t to Marcus for sending them to us):

Here are pdf snapshots of those posts made on 10/4/2023:

Error in vroom_ when reading reports with blabr

> fixation_report <- read_fixation_report(fix_rep_path)
Error in vroom_(file, delim = delim %||% col_types$delim, col_names = col_names,  : 
  embedded nul in string: 'R\0E\0C\0O\0R\0D\0I\0N\0G\0_\0S\0E\0S\0S\0I\0O\0N\0_\0L\0A\0B\0E\0L'

Normally, reports are encoded using UTF-8 encoding but in two cases already the files were in UTF-16 LE. If this becomes a common occurrence, we might add an encoding option to read_fixation_report and read_message_report. For now, however, let's convert the file to UTF-8 instead and only commit the UTF-8 version to the repo. 

input_file <- 'fixation_report.xls'
output_file <- 'fixation_report.tsv'

input_file %>%
  readr::read_lines(locale = readr::locale(encoding = "UTF-16LE")) %>%
  readr::write_lines(output_file)

Also, try reexporting with the setting below (the checkbox should be checked!). Please update this page once you try so that we know if that helps or not.

PreviousEyetrackingNextEye Tracking Data

Last updated