Hi Jenny,
You suggested that the Eye Position data stream could be used to do blink detection.
I am noticing that the EyePosition.Next Event seems to fire separate events into the stream for each eye and that the EyePositionEventArgs contains either a valid LeftEye.IsValid value or a RightEye.IsValid value but does not include valid values for both eyes at the same time, when both are open. Naturally if neither eye is open, then the event does not fire.
As you suggested this is enough to detect blinks in individual eyes from the delta between individual Timestamp values.
I did find however that with a stream of independent eye events that detection of when a particular eye is closed was a little awkward with the current event arg data. A dispatch timer provided me a messy work around this by providing a way of timing out an eye tracking variable (aka programmatically turning off an eye indicator at a predetermined interval) if its datetime tick elapsed value exceeded a given timer interval. This however slows down my gaze indicator transition animation and/or causes my eye open indicators to flicker a lot. Whereas the system eye indicators that Tobii provides near the bottom of the screen are nice an steady.
Besides considering the possibility of adding native blink detection event support, it might also be nice if future versions of this sdk could enhance the EyePosition stream event to also pass a LostEyePosition event which would make both blink detection and eye open status more manageable in the client. Other possible ways to address this might be to include something in the individual event arg that indicated the current state of the other eye, and that way each EyePositionStream event had enough information in it to determine the state of both eyes at once. This last idea however would not help with detecting when the user closes both eyes since no event would fire and some sort of background timer strategy in the client would still be necessary to detect that scenario.
Perhaps you folks already have plans to fix this issue, but I thought I would throw something out there while I was wrestling with it in the alpha version of the SDK.
Thanks.