Home › Forums › Eye Tracking Devices › fixation jitter › Reply To: fixation jitter
thank you very much for your detailed answer, and the additional interesting background information.
My concept of fixations in the first place was/is: a user”staring” intentionally at a specific point with the effort to not deviate from this point as good as possible.
The resulting position coordinates than build a curve I described as “jittery”, because it is not the perfectly flat line, which it can’t be, due to the eye motoric’s dynamic nature (micro saccades).
The info you hinted me describes that very well and so far confirms my understanding.
My measurements yield a STDEV of e.g. 6, or 1,2% for the amplitude in relation to the absolute coordinate origin, and that would be a quality that one can perfectly make use of. Esp. if these position data are referenced to using a representative characteristic value, such as MEAN.
That’s all fine.
Problematic for me is that the amplitudes of the fixations are almost indistinguishable from those to measure for smooth pursuits eye movements at low rates. Which is not what I had expected and which I have to investigate further.
And secondly, and the issue that led me to scrutinizing the constancy of position coordinates in fixation mode in the first place was s.th. else which now turned out to be an issue with time stamps actually:
If I calculate the derivatives of the positions (velocities, accelerations) hefty peaks show up, randomly, and not rarely.
I found this is linked to the non equidistant timestamps (caused by the non-uniform sampling rate which is a trait by design of the EyeX, as I understand, which also is expected).
Those peaks are rooted in very low time stamp deltas (very much lower then the neighbouring time stamp deltas), which then account for peaks with an amplitude of multiple 10.000 (!) of the base value when calculating derivatives.
The problem for me is: this happens randomly, and peaks are not perfectly discrete (i.e. single values in a fashion of outliers, which would ease filtering them out using appropriate filters), they rather still build up, just in a very brief amount of time.
Since they occur for fixations and smooth pursuit eye movements, I effectively don’t have a a truly constant or stationary signal, which therefore is not usable for what I have to accomplish: using constant/static gaze states as event triggers reliably.
I now wonder, whether those super low time stamp deltas are due to the tracker resetting s.th., thus part of it’s operation behavious?
Or may the device have simply hardware issues?
My understanding so far was: the sampling rate is adapted to the current gaze input, and fast gaze state changes may cause the tracker’s firmware to drop the frame rate in order for the tracker to keep up with the input (or vice versa, depending on other goals).
But that is not in line with what I observe in my situation, as these super short time stamp deltas show up in smooth pursuit eye movement and even fixation phases, and not during saccades…