Open GoogleCodeExporter opened 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
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
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
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
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
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
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
Here is the file I am using.
Original comment by grace.le...@gmail.com
on 25 Mar 2015 at 7:07
Attachments:
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:
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
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
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
@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
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
Original issue reported on code.google.com by
grace.le...@gmail.com
on 23 Mar 2015 at 10:18