Mismatch between Raw Eye-Tracker Data and MonkeyLogic eye x and eye y

Hi Jaewon,

We examined eye jitter during the fixation period, when the subject maintained gaze at a fixed position on the screen.

The eye-tracker camera data clearly show small fluctuations (jitter) in both the horizontal (X) and vertical (Y) eye-position signals. This is expected, as small involuntary eye movements (e.g., fixational eye movements) typically occur even when a subject is fixating on a stationary target. However, when the same data are recorded and viewed in MonkeyLogic, the eye-position values appear constant, with no visible jitter. This was unexpected.

Could you please let us know if there is any specific reason why MonkeyLogic shows constant values during fixation? Additionally, is any processing, filtering, smoothing, quantization, or other transformation applied to the raw eye-tracking data before it is stored by MonkeyLogic during recording?

We would appreciate any insights you can provide. Camera FPS is 250 Hz.

Thanks

Would you first explain how you recorded the eye signals? Are you using an NI board or a TCP/IP connection?

If this is true, it means that the eye cursor did not move at all during fixation. Is that what you observed during the recording? That would have looked very strange, if you were watching the control screen.

Did this occur only during fixation? Have you checked the entire signals?

We are streaming eye-tracking data into MonkeyLogic via a UDP connection (please see the attached figures for reference).

In the attached trial figure, the main saccade is clearly captured, but the fixation periods before and after the saccade show completely flat, constant values. This is highly unexpected because the raw data sent over UDP uses a high-precision, 16-decimal float, and the exported CSV file clearly shows normal eye jitters and microsaccades during these exact intervals.

It seems like MonkeyLogic is losing this precision internally and flattening out the micro-movements during fixation.

Please let me know if you need any further information.

It appears that you are testing a custom eye tracker.

There could be several reasons for what you observed, but, at first glance, the eye traces look too smooth throughout, not just during fixation. Did you write the eye tracker software yourself? Could you show me the code that converts the eye positions into a string?

I'm not exactly sure what you mean by "high-precision, 16-decimal float," but, as I mentioned in the manual, this UDP/TCP interface accepts only single-precision floating-point values. That means the values can have only 6 to 7 significant decimal digits, which is typical of most commercial eye trackers. I may be able to run some tests if you let me know the format of the strings that your eye tracker sends to NIMH ML.

Hi Jaewon,

We have solved this issue now. The problem stemmed from extra filtering by the eye tracker, which resulted in constant value readings.

There’s just one remaining concern. When we use a larger target location (-9,9)—which is approximately 12.7 degrees from the center—the eye x and y values tend to get clipped at 10 degrees. Could you kindly suggest a solution for this? I’ve attached two photos for reference.

Both in the manual page I linked above and in the My EyeTracker setup menu, I stated that the eye X and Y values should be in the range of -10 to 10. Transform your device's output values to the range of -10 to 10 before sending them to NIMH ML.

Got it. Thanks!