Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Missing samples from SMI RED250 Mobile

Hi all,

Did anyone here experience missing samples from the eye recording when using SMI RED250 Mobile eye-tracker?

I recorded pupil size using said eye-tracker (ET) and EEG at the same time. I sent trigger codes via a parallel port to EEG and messages that were in sync with the trigger codes via ethernet to the ET. The ET sampling rate was 250 Hz, but it actually never recorded at 250 Hz. The sampling rate often dropped to 190-220 Hz in a 5-min experiment. In an extreme case, the ET sampled in 18 s instead of every 4 ms.

I wonder if this problem is unique to the PyGaze-OpenSesame combination with SMI or it is the ET that is problematic. As a context, my colleagues who experimented using Presentation did not seem to have this problem.

Any help/idea is appreciated.




  • Hi Intan,

    There aren’t any pauses like that programmed into the source code on my end, and I doubt there are in the SMI SDK (on top of which the current PyGaze implementation is built).

    I don’t personally work with SMI trackers, but have heard from colleagues who do that their devices can suffer from irregular sampling. That said, the 18 second gap you mention is HUGE, and I would think that’s likely a product of a different problem than dropped samples. (Did the tracker lose the eyes and did it stop reporting?)

    So, in sum, I think there might be two superimposed issues: 1) Dropped samples, which as I understand is quite common for SMI trackers, and 2) Some unknown reason for signal loss.

    To make things easier computationally, I would recommend adding “start_recording” and “stop_recording” items within your trial logic, so that the tracker has time to get rid of internal buffers while it’s not recording. (This is helpful for some trackers, might not be for SMI, really depends on how their SDK works internally, which we as non-SMI people have no insight into.) I would also try to make sure that your participant is doing exactly what you want, and that they are easily trackable. (Maybe test them in the same experiment in OpenSesame and Presentation?)

    Finally, I’m afraid there’s little I can do if it does turn out that the problem is software-specific. The SMI implementation is a relatively straightforward wrapper around the SMI SDK, which handles all the data streaming. Which means that the problem might be in the API rather than in PyGaze, and considering SMI was bought by Apple, it’s unlikely they’ll fix their API… :(



    Thanked by 1intanwardhani
  • Hi Edwin,

    thank you so much for your prompt response! 

    I was already convinced that it's not in the source code of PyGaze. This was confirmed a few days back after I ran several experiments with OpenSesame and Presentation and compared the results. The analysis showed that I lost 16-27% of data samples. I also checked my colleague's data collected with Presentation from 2 years ago and there was "only" 0.2% data loss.

    I did various things to try to find out what is wrong, including adding "start_recording" and "stop_recording" items in my trial logic. Unfortunately, that did not make a change. Instead, it gave me a problem with the synchronisation of the ET and EEG data. I checked the SMI PC's memory and RAM. The result showed that both were still functional. It is quite puzzling to me what may cause the timing problem.

    Another weird SMI behaviour that I discovered is the incorrect timing. Calculating the difference between the next and previous samples yields a negative value, indicating that the timestamps go backwards. Moreover, in my experience, the iViewX often had difficulties in detecting the ET or finding the server. So, I had to restart the computer prior to starting the experiment, but not during the experiment. Some other people had it that it stopped recording in the middle of the experiment, hence the data loss.

    I'm not sure if this will fix the problem because I haven't tried it yet, but perhaps changing the ET cable could help. Sorry that there seems to be no solution here...



Sign In or Register to comment.