- 05/02/2019 at 16:12 #9310
I’ve been working with the coreSDK and eyeX recently, and I’ve run into an issue with the fixation stream in both the provided github examples and my own code — the end point of a fixation will often have X and Y coordinates that are NaN. I haven’t seen this behaviour documented anywhere, and it has occured on multiple trackers, so doesn’t appear to be a hardware issue. Is this the result of losing tracking before a fixation is complete?
I have also been trying to change some aspects of the calibration, and have seen the Stream Engine API mentioned as being able to change some parameters of calibration, such as the number of points, but I haven’t seen this mentioned in the Stream Engine documentation. Is this feature still available? Ideally I’d like to be able increase the number of points in the calibration, and, since I only need to track over a small portion of the screen, perform the calibration over the relevant area only, rather than the whole screen.
Will05/02/2019 at 22:14 #9312
Hi @willmccaff and thanks for your query. With respect to Nan reported in fixation location, this indeed can be caused by gaze data either falling out of tracking range or that the eye movement itself was sufficiently erratic so as to not qualify as a true ‘fixation’. for example if you look rapidly from one screen edge to another, this will not be calculated as a fixation. One way to have a look exactly as to what is happening is to analyse the raw gaze data locations as reported by the SDK as see how they look over time. This should allow you to determine what might be the issue. Certainly, if the eye gaze focus is steady within a relatively small area on screen, you should receive valid co-ordinates for fixation.
Regarding custom calibration, you are Correct that this may be implemented in the Stream Engine API however this requires the purchase of a special custom calibration licence to do so. You can request a quote for this by email the licencing team directly at [email protected]
Please have a look at your gaze data and report back here so we can continue to help you in resolving any issue that might be present. Best Wishes.06/02/2019 at 15:48 #9313
Would I then be correct in saying that the fixation stream does not exlusively report valid fixations? That being the case would the best practice to be to discard any fixations that terminate with NaN?07/02/2019 at 15:19 #9321
Hi @willmccaff, yes it would be best practice to discard those fixations although if you feel these are being reported with too high a frequency, then it would be worth investigating further to determine any possible issues with calibration or user profile as the root cause.10/02/2019 at 17:22 #9326
That sounds good, thanks for your help!
Will10/02/2019 at 22:08 #9332
Our pleasure to help! Please let us know if we can be of any further assistance 🙂
- You must be logged in to reply to this topic.