EEG and event markers not syncronized in .xdf recordings from SNAP/LSL/LabRecorder.

[GoogleCodeExporter]

What steps will reproduce the problem?

I've recorded a dataset using LabRecorder (for EEG) and SNAP (for event 
markers), and imported it using the XDF Importer plugin for EEGLAB.

What is the expected output? What do you see instead?

The timestamps for the EEG data start at "Zero" and end at 692.65 (Epoch End)
But the timestamps for events created by SNAP seem to be in "seconds since the 
computer was turned on", very large numbers. Of course when I try to epoch in 
EEGLAB I get an error saying they are out of the dataset boundary.

What version of the product are you using? On what operating system?
Running LabRecorder and SNAP on Windows 8.1

Original issue reported on code.google.com by grace.le...@gmail.com on 23 Mar 2015 at 10:18

[GoogleCodeExporter]

Hi Grace! I am currently managing labstreaminglayer.

Did you record the timestamps in SNAP? I.e. are there two separate XDFs that 
you are loading into EEG lab? The reason I ask is that load_xdf.m (which is 
actually part of mobilab) along with dataSourceXDF.m collectively have a 
routing for zeroing out timestamps when you load an XDF file.

Indeed, the timestamps attached by LSL are often huge numbers and differ from 
computer to computer -- it's current CPU time. Hence, the zeroing out process. 
If you record both data streams into the same XDF with LabReorder, you should 
be fine.

Original comment by david.er...@gmail.com on 23 Mar 2015 at 4:45

[GoogleCodeExporter]

Hi David,

I recorded both streams into the same .xdf file using LabRecorder. I then used 
the xdfimport1.08 plugin within EEGLAB (which is using load_xdf). 

This is what ends up in my "Streams" variable when I run load_xdf directly. The 
timestamps are in the same units, but not zeroed properly.

>> Streams{1,3}.info

ans = 

               name: 'EEG'
    first_timestamp: '-2041.090439'
     last_timestamp: '-1348.913871'
       sample_count: '152384'

>> Streams{1,4}.info

ans = 

               name: 'SNAP-Markers'
    first_timestamp: '1921.060913632'
     last_timestamp: '2559.083428821'
       sample_count: '25'

Original comment by grace.le...@gmail.com on 24 Mar 2015 at 8:41

[GoogleCodeExporter]

Sorry I was unclear in my first post-- I was using LabRecorder to record all of 
the streams together into one xdf file.

Original comment by grace.le...@gmail.com on 24 Mar 2015 at 8:49

[GoogleCodeExporter]

And I presume that the version of load_xdf corresponds to the version of 
xdfimport?

Original comment by david.er...@gmail.com on 24 Mar 2015 at 6:27

[GoogleCodeExporter]

This issue seems to be about load_xdf and xdfimport, so I have migrated it to 
the xdf issues wiki:
https://code.google.com/p/xdf/issues/detail?id=1

Original comment by david.er...@gmail.com on 24 Mar 2015 at 6:34

• Changed state: Duplicate

[GoogleCodeExporter]

Migrating the issue makes this harder, so I am reopening this.

So I tried to recreate the problem, but could not succeed. I did import some 
data using the latest version of eeglab and xdfimport (which is 1.12). I 
obtained xdfimport by first getting the latest version of eeglab and then under 
File->Manage EEG Extensions->Data import extensions checking the box for 
xdfimport. Then, eeglab dis its thing and everything worked. 

Also, I perused the code for xdfimport1.08, and it should be subtracting the 
first timestamp from the markers code.

Is the markers stream of the type either 'Markers' or 'Events'? If not, this 
may cause problems. You can check this by loading it the xdf with xdfimport:

>> streams = xdfimport('xdf_file.xdf');

and then

>> streams{stream_no}.info

where 'stream_no' corresponds to the marker stream. It should print out 
something like this:
ans = 

               name: 'trigger'
               type: 'Markers'
      channel_count: '1'
      nominal_srate: '0'
     channel_format: 'string'
          source_id: 'Markers'
            version: '1'
         created_at: '1823099.517469486'
                uid: '3aad65f9-b46f-4451-9154-87bd99276eed'
         session_id: 'default'
           hostname: 'install'
          v4address: [1x1 struct]
        v4data_port: '16572'
     v4service_port: '16572'
          v6address: [1x1 struct]
        v6data_port: '16572'
     v6service_port: '16572'
               desc: [1x1 struct]
      clock_offsets: [1x1 struct]
    first_timestamp: '1823186.041061342'
     last_timestamp: '1823270.115988703'
       sample_count: '170'

The field 'type' must be either 'Markers' or 'Events' or else I don't believe 
it will work.

Original comment by david.er...@gmail.com on 24 Mar 2015 at 7:51

• Changed state: Accepted

[GoogleCodeExporter]

Hi David,

I was indeed using an older version of the XDF import plugin I had found here:
https://code.google.com/p/xdf/downloads/list

However, when I follow your directions to update to version 1.12, there is no 
xdfimport.m file in the new plugin folder. There is loadxdf.m, when I run it I 
get the same result I posted in comment £2, where the EEG and Marker streams 
are not synchronized.

Original comment by grace.le...@gmail.com on 25 Mar 2015 at 7:05

[GoogleCodeExporter]

Here is the file I am using.

Original comment by grace.le...@gmail.com on 25 Mar 2015 at 7:07

Attachments:

• EyesOpenClosed.xdf

[GoogleCodeExporter]

OK, so after some investigation, I believe that something went wrong in the 
timestamping of this recording. The reason for this? I have no idea. But I can 
definitively say that the timestamps of stream 3 are incorrect.

The way it works is that as data is being recorded by labrecorder, a record is 
kept of when those samples come in relative to the clock on the data recording 
computer. This time series is then used to synchronize all the streams that 
were recorded, perhaps from different machines. If all the streams were 
generated by the same computer this has little to no effect on the timestamp 
data.

After this mapping is done, the streams are now synchronized relative to the 
recording computer baseline, i.e. they all have roughly the same range. Then, 
to arrage it so that the data begins at time '0', the lowest of all the 
timestamps is simply used to offset the timestamps of all the streams.

So what seems to have happened in this recording, and I can't for the life of 
me think of any reason that this could happen, is that the timestamps of stream 
3, disagree with the relative clock offset that gets kept track of in the 
background of LabRecorder. The result of this is that the timestamps of stream 
3 begin at some large negative number (around -2000) while the other 3 begin at 
somewhere around 1900. Then, the offset that should be zeroing out the 
timestamps is -2000, when subtracted from 1900 or so is about 3900 or so.

Attached are plots of the clock offset data for each stream, the pre and post 
mapping timestamp data and the post-zeroing out process.

Please let me know if you encounter this problem again or if you experience any 
more trouble with LabRecorder. I am really quite stumped as to how this could 
have happened.

Original comment by david.er...@gmail.com on 26 Mar 2015 at 7:04

Attachments:

• clocks.png
• before.png
• after.png
• zero.png