Hi Chris,
Hope you’re doing well. Alina and I were playing around with the eyelink system this afternoon because in one of the rigs, setting eye_in_window to true was not working correctly. We found that this particular eyelink had a different sampling rate than all the others. It was sampling at 1000, which is the same sampling rate in mworks, and our other eyelink systems sample at 500. Once we changed it to 500, it fixed the eye_in_window issue, but I’m wondering if we should keep it at this lower rate and how the lower rate is affecting sampling. Is there a chance that it would change what mworks is recording as a correct fixation?
Thank you,
Sarah
Hi Sarah,
When you say that 1000 is the sampling rate in MWorks, do you mean that the data_interval parameter of the experiment’s eyelink device is 1000 (i.e. 1ms)? I guess it’s possible that, with the EyeLink sampling the eye positions more frequently, MWorks and/or the EyeLink API can’t keep up with the increased amount of data. That said, based on the MWorks code, it seems like the extra samples would just be delayed by half the sampling period, and I don’t know why that would affect the fixation point’s trigger_flag output. It might affect the eye monitor, though, since two back-to-back eye samples with different positions could cause it to compute a high eye speed due to the short time interval between the samples.
As for whether 500Hz vs 1000Hz on the tracker makes any difference, I’m inclined to think not. If you want to leave it at 1000Hz, then you could try reducing data_interval to 500 (i.e. 0.5ms) in your experiment. That way, MWorks would retrieve the eye samples twice as frequently, which should prevent the backup I described previously (if that is indeed the issue).
Cheers,
Chris
Hi Chris,
I tried it out last week to see if it made any obvious difference and it doesn’t seem like it. There may have been some underlying reason that Sachi increased the sampling rate in this Rig so I’m going to try to reach out to her.
Thanks for the information!
Sarah