Missing samples from SMI RED250 Mobile

Comments

• Edwin

  September 2019

  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… :(

  Cheers,

  Edwin
• intanwardhani

  October 2019

  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...

  Cheers,

  intan
• WSS

  July 2020

  Hi Intan,

  I just found your question today and if you have no solution to your problem yet you might want to try this.

  We had some issues with the same SMI tracking device and the recordings on the laptop delivered by SMI. Even SMI (when the company still existed) could not explain what we found out and they did not have a different solution than we had. A quite strange and annoying one as I must say.

  We used at that time the original Experiment Center and BeGaze from SMI. BeGaze showed that the tracking ratio of our recordings was very low (huge amount of lost eye tracking data). I found out that iView internally lacked some timing when we did not connect the webcam whish you can use for a video recording of the person you want to track. When we connected the cam and switched on the audio(!) recording all tracking ratio problems disappeared instantly.

  Within the Experiment Center there was a checkbox for audio recording which you could only tick when the video recording was ticked, too.That did the thing and all recordings were far better than before. I tried several things but it really was the audio recording that only runs together with the video recording. Although there is much more data processed the eye tracking did run properly and whenever we disabled the audio recording the tracking ratio went from e.g. 97% down to 60% or even lower to somewhat 45%. Not even SMI itself could explain that behaviour but it was the only working solution for us.

  Within our university I found a different team with the same SMI equipment and could test both devices seperately on both SMI laptops. It was not the device that made problems. It was something in the laptop configuration. When that was clear, at that time SMI did not do any hardware check any more and their suggestion was to use the initial SMI backup on the machine to reset the complete system to the conditions when we bought it. Unfortunately we and even the rest of the SMI clerks could not say which backup solution they used to create that initial backup because every co-worker there had used a different solution and the last man in support did not know anything about the file extension and the appropriate software. So we never managed to restore the laptop setup.

  So in the end we stayed with this video/audio recording and our tracking ratios were really good. But we did not use the system for quite a while now. When we get back to it we will probably use OpenSesame or E-Prime for the experiments and abandon the SMI software. I did not find any functions for the video and audio settings in the SDK so I do not know how to work with the problem then. But perhaps you can at least check with Experiment Center and BeGaze if this is the same issue than ours.

  Greetings,

  Alan Smithie