This project has moved. For the latest updates, please go here.

Mirametrix: Raw data not evenly distributed

Aug 27, 2012 at 1:27 PM
Edited Aug 27, 2012 at 1:29 PM


I acquired data with Ogama and the S2 Mirametrix eyetraker. I would like to use the raw data directly. However I notice that the time stamp in the raw data are not evenly distributed. The eyetracker has a frequency of 60Hz I was expecting data in the range of 16~20ms. But this is what I have when I look at the raw data tab from the database module:

  ID SubjectName TrialSequence Time PupilDiaX PupilDiaY GazePosX GazePosY MousePosX MousePosY
  1 Sophie 0 26 9.490000 10.660000 334.003174 138.997757 670 480
  2 Sophie 0 146 8.260000 10.990000 304.998413 56.995838 861 250
  3 Sophie 0 146 8.260000 10.990000 289.996796 -7.004160 861 250
  4 Sophie 0 146 8.970000 10.620000 304.000000 120.995842 861 250
  5 Sophie 0 146 8.140000 10.400000 290.995209 80.998398 861 250
  6 Sophie 0 146 8.140000 10.400000 288.998383 74.997757 861 250
  7 Sophie 0 146 9.390000 11.040000 270.003204 216.995834 861 250
  8 Sophie 0 146 8.340000 10.540000 424.998413 91.996162 861 250
  9 Sophie 0 154 8.340000 10.540000 448.000000 -16.005119 861 250
  10 Sophie 0 197 9.300000 10.620000 385.996826 112.005119 859 246
  11 Sophie 0 197 8.940000 10.540000 472.998383 132.997116 859 246

There is a jump from 26 to 146 - 120 time units (ms?). It also appears that I can have more than one entry for the same time. And then there is a gap of 8 time units.

Can you please explain what's happening? did I miss a step to retreive the raw data?

Thank you.



Aug 27, 2012 at 4:07 PM

Hi Sophie, the interface for the S2 is written by Mirametrix itself, so my help is just a try. You are right that it makes no sense to have multiple gazeposition data at the same timestamp (which is in milliseconds, yes). I´m quite sure that this is a latency problem with the cpu power. It would be of interest, if later data samples are more evenly distributed, you have just shown the first few samples which may are disturbed cause of the "much things to do at the beginning of the presentation". The timestamp is evaluated internally whenever ogama receives the message, that there is a gaze sample available, which can be due to processor load stacked. The time is not given from the tracker itself. So there may be two or more messages on the stack before they can be processed, which then are processed whithin some microseconds having the same timestamp. The gaze data is correct, because it is delivered from the s2 device directly.

So my expectiations would be -> reduce the processor load (or use a more powerful hardware, including memory) and this problem will disappear and also I think it will increase stability on progress of the trial. Maybe we can adapt the interface some time, that it uses the S2 timestamps themselves, which would also solve this problem.

Regards, Adrian

Aug 27, 2012 at 5:18 PM
Edited Aug 27, 2012 at 5:21 PM



I thank you for your prompt answer.

I looked at the data and this also happens later in the experiment. I looked at another experiment that have less multiple entries for a timestamp. I computed the mean and standard deviation of the elapse time (ET) between two measurements. I have ET = 54.22 ± 37.88ms which is far from the 16ms(60Hz).

I will contact the Mirametrix support to have more information. I also had questions about the parameters for the fixation detection but since my raw data are not right that probably mess up the computation. I might come back to you later on this.

I thank you again.


Best regards,


Aug 27, 2012 at 5:51 PM

Yes, you are right, when you have samples at about 20Hz the fixation detection algorithm will surely fail. Let me know what mirametrix says, what about your hardware (processor and memory?)

Aug 30, 2012 at 5:35 PM
Edited Aug 30, 2012 at 5:35 PM


I'm still waiting on the mirametrix answer. For the data that matter the most for me (the experiments that have  ET = 54.22 ± 37.88ms ) I don't have the hardware specifications.

I looked at the raw data a little more and I found that I have the infinity value for the average saccade velocity.

Trial: Duration (ms) Gaze: Fixations (count) Gaze: Fixations (count/s) Gaze: Fixation Duration Mean (ms) Gaze: Fixation Connections Length (px) Gaze: Path velocity (px/s) Gaze: Average Saccade Length (px) Gaze: Average Saccade Velocity (px/s) Gaze: Fixation/Saccade ratio
8522 10 1.173433 557.3 11742.54 1377.909 1304.726 9.511294 653.9544708
5364 4 0.7457122 258.5 811.9421 151.3688 270.6474 0.864052 192.7665921
17077 14 0.8198161 472.2142857 15732.26 921.2546 1210.174 Infinity 387.1288868
8042 6 0.7460831 525.5 5071.925 630.6795 1014.385 4.143814 392.0666501
6358 6 0.943693 659.8333333 12734.09 2002.846 2546.819 24.03726 622.6800881

I think it is computed from the average saccade length divid by the timespan. But I didn't find how the timespan is evaluated . Can you give me more details about this?

Thank you so much.



Jul 2, 2013 at 3:55 AM
Hi Sophie

I came across your post when trying to work out why I was getting the same kind of pattern with Mirametrix S2 data, i.e. big time jumps between entries, multiple entries with the same time stamp. I did an additional calculation, which was to take the total time lapsed and divide it by the number of records in the output file. That gave me an average of 16.5ms, which is pretty close to 60Hz. So it looks like the relevant number of samples is being saved, but the time stamps can't be trusted.
Did you hear anything back from Mirametrix?

Jul 2, 2013 at 11:06 AM
Hi Paul,

No, they never reply to my e-mails. At least you have the frequency right, I did the same calculation with the data I had an the frequency was about 20Hz.
I was not the one who did the experiment and I coudn't access the equipment to investigate more about this issue.
We just went back to the software that mirametrix provides to acquire the data.
Good luck.

Jul 13, 2013 at 6:42 PM
Hi Sophie, some late answer to your infinity question...
The saccade velocity is calculated in the method GetSaccadeArrays in the class Ogama.Modules.Statistics.Statistic.cs
basically it calculates currentSaccadeLength / currentSaccadeDuration
so there must be a saccade duration of zero somehow, which is an artifact of a wrong fixation calculation,

For anyone who is curious about how the statistical data is calculated, have a look at the source :-), the above mentioned class is your friend.
Kind regards,
Jul 13, 2013 at 6:46 PM
Hi Sophie, Hi Paul
if you are able to provide me with an description of the S2 messages, then we might fix the timing issue, if is up-to-date (some time ago, you posted).
If there is a document explaining BPOGX or LPD messages then there may be a message for the time stamp, so that we can use the S2 timing directly.
Kind regards,
Jul 14, 2013 at 10:02 AM
I updated the mirametrix interface with changeset bcd53890d908, so it uses the mirametrix timing. I cannot test it, cause I have no S2 device. Please try it using the sources and give some feedback.
Kind regards,
Jul 15, 2013 at 12:47 PM

Thank you for your reply.
As I said earlier, I cannot experiement on the issue since I don't have access to the same set up.
I hope that the change you made will help.
Best regards,