Devel: BCILab hangs on reading data from LSL stream

[haniawni]

When using the devel branch of BCILab (1.4-devel) with Matlab 2015b on MacOSx 10.11.5, BCILab boots without issue, and menus can be browsed/etc.
When selecting Online Analysis -> Read input from... -> Lab streaming layer..., the window run_readlsl() opens, and the user can specify stuff to connect to/parameters just fine.

However, once the user selects "ok", BCILab simply prints "Looking for a device with type='EEG' ..." and fails to actually do anything. Attempting to use the BCILAB window then results in erroneous behavior, with menus highlighting but failing to open and buttons not actually doing anything.
When the user sends a keyboard interrupt in the Matlab command window, all the user's button presses go through in sequence, implying the attempt to find the LSL stream is hanging.

I'm demoing this on a single machine, running both LSL's SendData.py (which sends random 8-channel data with stream name="BioSemi" and type="EEG") and Matlab/BCILAB. Note that SendData.py is working, because I can concurrently run LSL's ReceiveData.py and print it.

Any idea what the problem is?

[haniawni]

Possibly relevant comment:
#19 (comment)
Indicates that by default LSL reader waits to try to find a marker stream as well.

Unfortunately, clearing the Marker Query field has no visible effect on the problem.

[dmedine]

I don't use BCILab on osx at all, but you might want to start by
verifying that you are able to receive lsl streams at all. You might
want to try the LSL ReceiveData.py if you haven't already, just to make
sure all that is working correctly. Next I would try to troubleshoot
matlab+lsl without BCILab. There are example scripts similar to the
python scripts for the lsl-Matlab wrapper. If you can send and receive
lsl streams via Matlab outside of BCILab, your problem will be beyond my
expertise to assist :(

On 7/14/2016 12:26 PM, Hani Awni wrote:

When using the devel branch of BCILab (1.4-devel) with Matlab 2015b on
MacOSx 10.11.5, BCILab boots without issue, and menus can be browsed/etc.
When selecting Online Analysis -> Read input from... -> Lab streaming
layer..., the window run_readlsl() opens, and the user can specify
stuff to connect to/parameters just fine.

However, once the user selects "ok", BCILab simply prints "Looking for
a device with name='BioSemi'" and fails to actually do anything.
Attempting to use the BCILAB window then results in erroneous
behavior, with menus highlighting but failing to open and buttons not
actually doing anything.
When the user sends a keyboard interrupt in the Matlab command window,
all the user's button presses go through in sequence, implying the
attempt to find the LSL stream is hanging.

I'm demoing this on a single machine, running both LSL's SendData.py
(which sends random 8-channel data with stream name="BioSemi" and
type="EEG") and Matlab/BCILAB. Note that SendData.py is working,
because I can concurrently run LSL's ReceiveData.py and print it.

Any idea what the problem is?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#20, or mute the thread
https://github.com/notifications/unsubscribe/ADch7g32mIb_24Lww_X_fhv5P1XQtC1uks5qVo1cgaJpZM4JMxCO.

[haniawni]

Hello,
Yep, LSL's ReceiveData.py can successfully print data from both the OpenBCI-python LSL plugin and LSL's SendData.py.

LSL's MATLABViewer app, vis_stream.m, can successfully connect and receive data from the OpenBCI LSL stream (or LSL's SendData.py stream), once settings have been changed according to this comment.

This means the issue lies in BCILAB's LSL-streaming plugin in the current version.
Hopefully, within a few days, I will be able to test whether this is Mac OSX specific, or if it's also a problem on Windows in the current devel-branch commit, e287299.

Thanks!

[haniawni]

Update: I believe the code is hanging in /code/online_plugins/run_readlsl.m, between the two print statements where it does this:

% look for the desired device
disp(['Looking for a device with ' opts.data_query ' ...']);
result = {};
while isempty(result)
    result = lsl_resolve_bypred(lib,opts.data_query); end

% create a new inlet & query stream info
disp('Opening an inlet...');

This means the code is hanging in lsl_resolve_bypred.m, which pretty much immediately calls the mex function lsl_resolve_bypred_.c
However, because I am able to run LSL's MATLABViewer app with the same stream, I checked if the two copies of the library have the same lsl_resolve_bypred_.c, and they do.

This means the error has something to do with how the LSL plugin is being initialized in BCILAB in comparison to LSL's MATLABViewer App. Next step is finding where that initialization happens.

EDIT: Hold up- the BCILAB/dependencies/liblsl-Matlab folder and labstreaminglayer/Apps/MATLABViewer/liblsl-Matlab folder have a bunch of differences. First next step is testing swapping out the BCILAB one for the LSL/MATLABViewer one.

[haniawni]

Ok. I have committed the cardinal sin of editing code that I do not fully understand, but it no longer hangs, and seems to be functioning properly? Though I'll have to do a bit more to test.

What I did was move the LSL/Apps/MATLABViewer/liblsl-Matlab from LSL's current github repo to replace BCILAB/dependencies/liblsl-Matlab, operating under the assumption that BCILAB's copy of liblsl-Matlab is simply out of date. With this change, BCILAB was immediately able to connect to the stream, but started spamming this error:

Error in block-reading function:
Too many input arguments.
occurred in:
run_readlsl/read_data: 183
@()read_data(inlet,marker_inlet,opts.always_double): 175
append_data: 86
@(timer_handle,varargin)append_data(stream_name,stream_id,timer_handle,block_reader): 0
timercb: 30
timercb: 13

That region of code is where BCILAB's run_readLSL plugin is querying the inlet stream, first for data, then for the time corrections, and there is where the problem lies:

180 function result = read_data(data_inlet,marker_inlet,always_double)
181 % get a new chunk of data
182 [chunk,stamps] = data_inlet.pull_chunk();
183 data_clock = data_inlet.time_correction([],opts.clock_alignment,opts.clock_est_window);
184 stamps = stamps + data_clock;

Line 183's function definition has been changed, in more recent versions of liblsl-matlab, to:
function result = time_correction(self,timeout)
with timeout as an optional variable. So in a drunken, incomprehending stupor, I did the following change to line 183:

   data_clock = data_inlet.time_correction(); % formerly called passing ([], opts.clock_alignment, opts.clock_est_window);

And it no longer complains, nor hangs, when attempting to connect to an LSL stream.
I will push this code, but consider it ludicrously untested. Writing to streams is almost certainly broken, and the time-correction behavior may be also borked.

Thus I have two questions for the sake of testing my duck-tape 'fix', @dmedine:

1. How can I get BCILAB to directly export the incoming LSL stream without making any modifications to the data, either into a file, or into an LSL stream for viewing in the LSL/MATLABViewer/vis_stream app?
2. is there some way I can, from within BCILAB, generate a test stream with simple properties (constant frequency sine wave, regularly spaced impulses, and perhaps a superposition of multiple sine waves) which I could write to an LSL stream (and ideally also visualize/write to a file) for the sake of testing?

[haniawni]

This change seems to work as well for writing to an LSL stream. My concern is that we lose some of the timing information/configuration for the stream.

Do you have some way to test the timing resolution of the version with my changes?

[brianbaloch]

Dear where is devel BCILAB which is error free?

[brianbaloch]

Thanks. I found BCILAB-devel