Synchronisation drift/delay with Brainproducts / LabRecorder

[ioannis-dz]

Synchronisation drift/delay with Brainproducts / LabRecorder

[ioannis-dz]

I run some more experiments, following a similar setup to the one for recording the BioSemi device latencies:

1. I used a Humisoft MF 624 DAQ card to produce a PWM pulse with a period of 250 ms and an amplitude of 50 mV
2. The PWM was then inserted to:
   • an A/D input of the DAQ card
   • a channel of the BrainAmp amplifier.
3. Both streams were recorded by LSL and an Event marker was sent by the A/D recording program when the voltage was sensed to be higher than 30 mV.
4. The difference between the Event marker and the BrainAmp recordings is the delay caused by the Brain Amp.

The results are an average delay of 51.65 ms ranging from 50.4 ms to 53 ms. Following are the histograms of the delay of two tests I ran, a 3 min and a 6 min recording:

The good news is that the delays are within a range of 2.6 ms so by removing a known delay of 51.65 we can get accuracies of a bit more than 1 ms which is great.

However, the delays are exceptionally high, about an order of magnitude higher than the delays of BioSemi in comparison. Especially for use with BCI such delays are very problematic.

[dmedine]

ioannis,
It is unlikely that anything is not properly aligned at the importing stage. There is also some amount of software latency depending on you computer and OS etc. These latencies you report are not terribly outlandish given other measurements that I have seen and taken.

Having said that, 30-50ms in the eeg recording data does seem like a lot. One question, are the latencies consistent from method to method? E.g, does BrainVisionRDA.exe always come ~40ms late?

I have done a number of synchronization/latency experiments already, although not with the brainamp products. You can read about it here:
http://sccn.ucsd.edu/labinfo/SCCN_latencies/index.php

I will attempt to make my own measurements if I can find some brainamp equipment lying around somewhere.

Also, if the latencies are consistent, you can easily compensate for synchronization purposes. You can add a line to the xdf header (using the XDFBowser app) to account for lag time. See the 'IMPORTANT!!' section of this page:
http://sccn.ucsd.edu/labinfo/SCCN_latencies/biosemi.html

[ioannis-dz]

David,

Thank you very much for your response.

A few comments based on your reply:

1. I have run a couple of tests to identify the stability of the delay, depending on the method the range is between 10 - 20 ms. (Eg. BrainAmp.exe has a range of 10 ms from 23-33 ms)
2. The actual delay is much larger. The hit event is already delayed by about 30 ms so the actual delay can be up to almost 100 ms depending on the method. (Eg. OVAS with size 8 chunks has delays in the range of 41- 62 ms with an effective delay of 70 - 90 ms)
3. Part of the range of this delay is definitely due to Unity and the event recording as that code runs only at approx 250 Hz producing a +/- 5 ms range on when the hit event will be reported to LSL.

Based on the above my plan was to record with whatever method has the least delay (most likely BrainVisionRDA.exe because I encountered some clipping issues with BrainAmpSeries.exe) and then remove the average delay from the EEG stream. That should be good enough for my analysis.

However if there was any way of dropping that recording delay or at least identifying the cause would be nice. I understand that a delay of about 50 - 100 ms is not outlandish but it does seem a bit odd as I would expect something in the region of an order of magnitude less.

Again, thank you very much for your help.

[dmedine]

Nice work! As you say, the good news is that the delay is consistent and the jitter is small. 51.65ms is, unfortunately, a lot for BCI applications,