sccn
LSL timestamps "jump" backward and forward
I used LSL to record EEG data from a LiveAmp 64 EEG device (Brain Products) and gaze data from a Pupil Labs Neon eye tracker for my study. While reviewing the LSL timestamps, I discovered that in a few of the EEG recordings, the timestamps unexpectedly jumped backward. As a result, all subsequent data points were shifted accordingly. This issue is illustrated in the following figure, where the x-axis represents the sample number and the y-axis shows the corresponding LSL timestamps.
Interestingly, at the same moment when the EEG timestamps jumped backward, the gaze data timestamps showed a forward jump. See figure here:
We were wondering whether this issue was caused by samples being recorded out of order and needing to be resorted, or if the timestamps themselves became incorrect from that point onward. Has anyone encountered this issue before, or does anyone know what might cause it and how to resolve it?
More examples:
What do you mean by "reviewing LSL timestamps"? Did you first record the data to disk? How did you do that? Was it with LabRecorder? How did you load the data to review? If you used LabRecorder to store the data to disk, then did you use pyxdf or xdc-matlab to import the data? If so, what options did you provide to the load_xdf method to post process timestamps?
What do you mean by "reviewing LSL timestamps"? Did you first record the data to disk? How did you do that? Was it with LabRecorder? How did you load the data to review? If you used LabRecorder to store the data to disk, then did you use pyxdf or xdc-matlab to import the data? If so, what options did you provide to the load_xdf method to post process timestamps?
Thanks for your reply! The data was recorded on a laptop using LabRecorder and loaded with xdf-matlab. No options were specified for post-processing the timestamps. The only input to the load_xdf function was the filename.
xdf-matlab does post-processing by default. See here.
You can try disabling different parts of the post-processing to get a better understanding of what's happening. My guess is that the jitter removal is trying to make all samples with even intervals based on the nominal rate, but the effective rate of the data is different from the nominal rate (due to one of the clocks being slower than the other) so after a while the 'jitter' that it's trying to correct is so large that a break is introduced.
xdf-matlab does post-processing by default. See here.
You can try disabling different parts of the post-processing to get a better understanding of what's happening. My guess is that the jitter removal is trying to make all samples with even intervals based on the nominal rate, but the effective rate of the data is different from the nominal rate (due to one of the clocks being slower than the other) so after a while the 'jitter' that it's trying to correct is so large that a break is introduced.
Thank you very much for your reply. I think you are right. I tried disabling jitter correction, and the data became noticeably more fluctuating. Then I enabled the correction and set the "JitterBreakThresholdSeconds" to a very large value, and the break didn't happen again.
Could you please explain a bit more about what you mean by "one of the clocks being slower than the other"? In my setup, EEG data was recorded with LSL-LiveAmp running on the laptop, while eye tracking data was recorded on a smartphone and streamed to LabRecorder via LSL-Relay. Would the LSL timestamps be affected by the clocks on the laptop and the smartphone?
In my case, I am using LSL timestamps solely to synchronize EEG and eye tracking data. Specifically, I want to find the closest EEG sample to each fixation point. If jitter correction was applied separately to the EEG and eye tracking streams, do you think that could influence the accuracy of synchronization?
I think it's better explained in the preprint: https://www.biorxiv.org/content/10.1101/2024.02.13.580071v2.abstract