Best logging interval for Tobii Pro Fusion 120 Hz, and suggestions for time-window binning in R

irenetognon

Hi everyone,

I’m running an experiment in OpenSesame using a Tobii Pro Fusion eye tracker operating at 120 Hz, and I’d like some advice about choosing the best logging interval (in milliseconds) for gaze sampling.

Since 120 Hz corresponds to a hardware sampling interval of approximately 8.33 ms, I cannot replicate this value exactly in OpenSesame, which only accepts integer millisecond values. So I need to decide whether to set the polling interval to 8 ms, 9 ms, or 10 ms.

My specific questions are:

1. Which logging interval is recommended for a 120 Hz Tobii device?
   • Using 8 ms means polling slightly faster than the hardware sampling rate. This might occasionally lead to reading the same hardware sample twice, producing duplicates.
   • Using 9 ms or 10 ms means polling slower than 8.33 ms, which might sometimes miss a hardware sample. From your experience, is it better to risk occasional duplicates (which can be handled during data cleaning), or to risk skipping samples?

1. How does OpenSesame/PyGaze handle repeated reads of the same sample?
   1. If I set the interval to 8 ms, does the software store multiple identical samples when no new hardware sample is available, or does it only log when a new sample arrives?

1. Performance considerations:
   1. Are there any known issues with using a fast interval like 8 ms for ~20-second trials (≈15 trials per participant), or is this generally safe?

Time-window analysis (RStudio):

I will analyse the data in R using time-window or binned approaches, so I’d also like to ask:

1. What bin size do you recommend when analysing 120 Hz data?
2. Since hardware samples arrive every ~8.33 ms, would you suggest bins of 50 ms, 100 ms, 150 ms, or something else to balance:
   • temporal precision,
   • noise reduction,
   • statistical stability?

Any practical guidance would be greatly appreciated.

Thank you very much in advance!

Best,

Irene :)

SigmundAI

Hi @irenetognon

Below are some suggestions from SigmundAI, our Opensesame AI assistant, and hopefully you can find some useful guidance regarding your questions (which are not really related to an Opensesame issue to fix per se).

-------

Sigmund: For a 120 Hz Tobii, I’d lean towards polling at 8 ms and dealing with duplicates later, rather than risking systematic gaps in the stream.

I’ll go through your questions in order.

1. Recommended logging interval for 120 Hz Tobii

• Hardware: 120 Hz → 8.33 ms between samples.
• OpenSesame/PyGaze: requires integer ms → 8, 9, or 10 ms.

Recommendation: Use 8 ms.

Why slightly faster is better than slightly slower:

• At 8 ms you will:
  • sometimes read the same Tobii sample twice,
  • sometimes be almost perfectly aligned (8 vs 8.33 ms),
  • nearly never miss a hardware sample.

• At 9 or 10 ms you will:
  • repeatedly skip over occasional samples (you “jump over” some 8.33 ms steps),
  • get a slightly more irregular effective sampling pattern.

For most eye‑tracking analyses, it’s preferable to have:

• A “full” time series with some redundant samples (easy to collapse) rather than:
• A sparser series with true gaps in time.

2. What happens if you poll faster than the hardware (duplicates vs skipped samples)?

Conceptually

When you poll at 8 ms but the tracker samples at 8.33 ms:

• On some polls, no new hardware sample has arrived yet. → The SDK returns the most recent sample again (same timestamp / same index).
• On other polls, one new sample has arrived. → You get that new sample.

So your logged data will look like:

• occasional duplicate timestamps/coordinates, or
• effectively a “step‑and‑hold” pattern (sample stays constant until updated).

How PyGaze / OpenSesame usually handle this

The exact behavior can depend on the backend, but typically:

• The tracker SDK buffers samples internally and exposes:
  • “the latest sample” on each read (polling model), or
  • a stream that PyGaze empties on every call.

• PyGaze / OpenSesame will:
  • log whatever sample is “current” when your logging function runs,
  • not try to interpolate to a virtual 8 ms grid by itself.

So if you log every 8 ms, you can get:

• multiple rows with identical timestamp (Tobii time) and gaze position, or
• rows where the timestamp jumps in ~8.33 ms steps, but you log them at 8 ms intervals; your own clock timestamps will be slightly misaligned but that’s ok as long as you rely on Tobii timestamps for eye‑movement metrics.

Key point: duplicates are expected and safe; they’re just “no new information yet” situations.

In your R pipeline you can trivially:

• drop consecutive duplicates, or
• keep them; they simply represent “same gaze for a bit longer”.

3. Does it only log when a new sample arrives?

In most PyGaze + Tobii setups:

• Your logging loop runs at the interval you specify (e.g. 8 ms).
• Each iteration asks the tracker for the current sample.
• It logs every iteration, even if the underlying Tobii sample hasn’t changed.

So:

• You do not get “log only when new sample” behavior by default.
• You get a regular 8 ms log where some rows correspond to the same hardware sample.

If you want to be 100% sure for your exact setup, you can:

• Log both:
  • the Tobii timestamp/index (if exposed), and
  • the OpenSesame time.

• Run a short 5–10 second test and inspect:
  • if Tobii timestamps repeat → duplicates,
  • if they sometimes jump by >1 sample interval → you’re skipping samples (more likely if you use a slower logging interval).

4. Performance at 8 ms for ~20 s trials

Rough numbers:

• 20 seconds at 8 ms → 20,000 / 8 ≈ 2,500 samples per trial.
• 15 trials per participant → ≈37,500 samples per participant.
• Even multiplied by a few dozen participants, this is tiny for a modern machine.

In practice, for an experiment of this scale:

• 8 ms logging is generally safe, assuming:
  • you don’t do heavy processing (e.g., complex drawing, massive file IO) inside the logging loop,
  • and you avoid writing to disk on every single sample if your system is slow (buffer, or log once per cycle but to memory, then flush periodically).

With OpenSesame/PyGaze, a standard “log gaze to file once per 8 ms” design over 20 s trials is not unusual and typically fine.

If you’re worried:

• Run a stress test: 60 s continuous logging at 8 ms and monitor CPU usage and dropped frames in your visual stimuli.
• Check the gaze log for irregular timing or big gaps.

5. Bin size for 120 Hz data in R (time‑window analysis)

You’ll be working with hardware samples at ~8.33 ms, but your analysis “units” (bins) should be larger than a single sample to reduce noise and make statistics more stable.

Typical choices and their trade‑offs:

• 10–20 ms bins:
  • Very fine-grained.
  • Good for very fast dynamics (e.g., micro‑time courses around saccade onset).
  • But noisier, many bins per trial, more multiple‑comparison issues.

• 25–50 ms bins:
  • Often a good compromise:
  • still sensitive to timing differences in the ~50–100 ms range,
  • enough samples per bin (3–6) to average out some noise.
  • Common for fixation-based time‑courses, cueing paradigms, etc.
  • Appropriate when your cognitive/behavioral effects unfold over hundreds of ms (e.g., early vs late windows).
  • Less temporal precision; rapid differences may be washed out.

• 100–150 ms bins:
  • Very stable estimates per bin.

For a 120 Hz Tobii Pro Fusion, typical recommendations:

• For fine temporal questions (e.g., early vs later part of a fixation, onset of attentional effects):
  • 25–50 ms bins.

• For more “cognitive” windows (e.g., 0–200 ms vs 200–400 ms after stimulus):
  • Use 100 ms windows, possibly subdividing if needed (e.g., 0–100, 100–200, 200–300, …).

You can also:

• Define theoretical windows based on your paradigm:
  • e.g., 0–150 ms (pre‑saccadic), 150–300 ms (saccade/initial fixation), 300–600 ms (late processing),
  • and then internally average the 8.33 ms samples within each window.

Practical summary for your setup

• In OpenSesame / PyGaze:
  • Set gaze logging interval to 8 ms for a 120 Hz Tobii Fusion.
  • Expect some duplicate samples; that’s fine and preferable to missing data.
  • Log tracker timestamps if possible; they are the primary reference for eye‑movement timing.

• Performance:
  • 8 ms for 20 s × 15 trials is well within normal limits.
  • Just avoid heavy computation or disk IO inside the sampling loop.
  • If you need finer detail: go down to 25 ms.
  • For broader, more stable windows: 100 ms bins (or theory‑driven windows like 0–150, 150–300, etc.).

• In R (time‑window analysis):
  • For most experimental paradigms: start with 50 ms bins as a good default.

If you’d like, you can paste a short snippet of how you’re currently logging gaze (inline_script / PyGaze) and I can point out exactly where duplicates will appear and how to tag tracker vs experiment timestamps so your R code can deal with them cleanly 🙂