ENH: Using 2-triggers to account for EEG-sound card clock drift

[rkmaddox]

We have recently discovered that the RME clock and the EEG clock run at ever so slightly different rates, slipping between 0.5 and 2 ms on a minute-long trial. There is a fairly simple fix, which is to use triggers to mark the beginning of the trial and another point or point(s) later in the trial.

This seems like a good use of the 2 trigger to us. A proposed solution would be that 2 triggers be sent at some configurable interval so their actual time compared to their nominal time tells us what the clock error is. A good default might be a 2 every 10 s. Trials less that 10 seconds are only looking at .2 ms accumulated error, so not so bad. If you were doing really long trials (say 60 s) and you wanted only one 2, you could set the interval to 50 s or something. There seems to be very little cost to anyone who doesn't have this problem of having an extra set of "timing triggers" in their recordings.

Thoughts?

[larsoner]

I don't see a problem with adding an option to the sound card triggering scheme to insert 2 triggers. I would say that the default should be just to add a single 2 to the end of the stimulus, no matter what its duration of the stimulus actually is. I have a feeling that this drift is going to be fixed across systems, so this can probably be estimated once during a given recording (likely EEG-sound-card pairing, but per recording to be safe) and having a 2 at the end of the stimulus will be enough to do this with accuracy down to the microsecond probably.

For related experiments and code, see https://github.com/mne-tools/mne-python/pull/8540. The TL;DR is that Neuromag MEG and EGI EEG systems recording simultaneously have this problem, and computing a linear drift term fixed over the recording seems to fix things so far.

For experiments that want to be extra careful (or for early testing), we can have a ec.set_sound_card_drift_interval(10.) to set it to something other than "start and end". Sound good?

[rkmaddox]

We could to that. It makes things a bit more complicated when there are variable-length stimuli, but perhaps we could jsut have one trigger time that can take either a number for seconds or a text input 'end'? It also would need to be a short period of time before the end of the stim, because the trigger has some duration.

Strangely, it is not fixed across systems, but it is stable over a recording. Our same pieces of equipment have shown different drifts over time, with a sudden change on one day that persisted. I think this is because we removed a piece of equipment that the RME had been sitting on, which very slightly reduced its temperature, affecting the resonance of the quartz crystal.

[rkmaddox]

Took a look at that other issue and yeah very similar. For us we've been handling it at the trial level and resampling the stimuli to the actual EEG sampling rate before regressing. Regardless, having those 2's should allow whatever compensation mechanism we decide on to be implemented.

[rkmaddox]

One of my lab members, Tong, has started to implement this for an experiment she is running, so she could open a PR.

[drammock]

This rang loud bells in my head, and I found an email from 2016 (!) where I noticed a bunch of clock drift warnings in a pilot I was doing, and never followed up on it :(

[larsoner]

It also would need to be a short period of time before the end of the stim, because the trigger has some duration.

Yes my plan was to have the default just be the last -n_samp_trigger: samples have the 2 trigger. It's either in this mode, or the mode where it has offset:offset+n_samp_trigger be the 2 trigger where offset iterates over 10 sec sample offsets or whatever.

One of my lab members, Tong, has started to implement this for an experiment she is running, so she could open a PR.

That would be great, happy to review!

[rkmaddox]

@drammock If it's any consolation, I had and fixed this issue with a TDT in 2017, and then proceeded to assume it wouldn't be a problem when switching to the RME...

[drammock]

closed by #424