parkslab / labstreaminglayer

Automatically exported from code.google.com/p/labstreaminglayer
0 stars 0 forks source link

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

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
Here is the file I am using.

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

Attachments:

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
Hi,
I know this thread is kind of old. But may I ask how did you produce markers 
with snap? I'm using muse device to to get EEG data. I send the data via lsl 
and record it with lab recorder to further use in EEGLAB/BCILAB. I just don't 
know and couldn't find any way to produce markers and send them to lab recorder 
via lsl (to record both EEG data and Marker events and use them in 
EEGLAB?BCILAB).
I would be really grateful if some one could help me with this.

Thank you!

Original comment by do...@vt.edu on 14 Jul 2015 at 7:06

GoogleCodeExporter commented 8 years ago
Hi,

I'm using SNAP to generate event markers: https://github.com/sccn/SNAP
Also I believe the new home for LSL is here: 
https://github.com/sccn/labstreaminglayer

Because of the issue described on this thread, it's currently not possible to 
record *any* other data streams simultaneously with the Muse EEG stream when 
the --lsl flag is used with muse-io (even the accelerometer stream from the 
headset cannot be recorded with the EEG stream, as the timestamps are not 
synchronized). This is a problem from the LSL implementation in the muse-io The 
current hypothesis is that the headset stream is dropping out frequently 
causing errors in LSL.

My current workaround is sending OSC out through muse-io and forwarding these 
OSC messages to LSL using a dedicated python script. Then one can use 
LabRecorder to record the event markers from SNAP with the forwarded EEG data.

Original comment by grace.le...@gmail.com on 15 Jul 2015 at 7:24

GoogleCodeExporter commented 8 years ago
Hi Grace,

Thank you so much for your response!

Aha, thank you. I downloaded SNAP now, but first I cannot launch the 
launcher.py. Because when I click on it, it appears for a second and then 
disappears again immediately! Also, may I ask for generating event markers we 
should write a code and script in SNAP? Because I don't know how to write a 
code in SNAP or Python :/

Aha, thanks again for the provided information. So, I can't use the --lsl arg 
in muse-io at all. May I ask how do you forward the OSC messages to LSL please? 
Also, is it possible to record forwarded EEG data and event markers stream from 
SNAP simultaneously in this way?

I'm really sorry for asking this many questions. I'm a civil engineering 
student and have no background with EEG, Python, SNAP and ..., and just started 
to learn EEG and its related stuffs for my research.

Thank you very much,
Donia

Original comment by do...@vt.edu on 15 Jul 2015 at 1:18

GoogleCodeExporter commented 8 years ago
@donia
Donia, please make any comments regarding issues on the new home for LSL on 
github:
https://github.com/
or our new mailing list:
https://mailman.ucsd.edu/mailman/listinfo/lsl-l

As for your problem with SNAP, it has to do with which version of python you 
are using. Managing python distributions can be complicated -- especially on 
Windows. I would recommend downloading a free IDE such as PyCharm. With this 
software, you can manage your projects and set which python interpreter to use 
on the fly. This is much easier than adjusting environment variables or the 
dreaded regedit in Windows. Please read the documentation for SNAP, Python, and 
PyCharm for more information.

Just for the record, the python interpreter you will need to use to run 
launcher.py is the one that ships with Panda -- the game engine that SNAP is 
built on top of. This comes with SNAP.

Original comment by david.er...@gmail.com on 15 Jul 2015 at 5:53

GoogleCodeExporter commented 8 years ago
Ok. Thank you for the information! Ok, I'll try IDE.
So I'm going to ask the rest of my questions on the new home for LSL on github.

Thanks,
Donia

Original comment by do...@vt.edu on 15 Jul 2015 at 5:57