Unfortunately there is no limit to the number of things that you could not anticipate and that go wrong while designing and running an experiment with human subject. I have to admit that this bug i found in my current design could have been anticipated with some more test. However that was not the case, so I found myself trying to re-synchronize the logs of each experiments which are stored on multiple machines, with their relative a-synchronized clock.
One of the limit of using 2 eye trackers is that if you need to confront the data you must have extremely well synchronized clocks, in the order of 50 milliseconds. Windows has a systematic lack of support for this kind of precision so I had to find other solutions, like using an atomic clock synchronizer. But even with that, the golden rule is: trying to keep the least number of machine involved in the data collection.
In my case I have three: two eye-trackers (windows) and a server which handles the messaging system (linux-box). After realizing that the clocks of the three machines have variables delays that change over time, I elaborated a strategy to re-sync the logs. It consists in watching the videos sampled on each eye-tracker at 15 frames per second and look for a specific event that appears almost at the same time in the two machines, like a message being posted on the server. Then I have a common event on the three machines that, besides network and processing delays, happened in the same ‘absolute’ moment. From there is just a question of doing the math.
The silly thing is that is not possible to automate this algorithm with a script, so I had to watch all the movies for extracting the relevant info. It turned out that also doing the math was somehow brain consuming, so I ended up offloading progressively my cognitive charge in favor of a paper based grid.
Here some more about my experiment.
Tags: