OpenViBE+OpenBCI Ganglion
in OpenBCI_GUI
Hello,
I tried streaming data using LSL protocol to OpenVibe Acquisition Server, and the results were horrible - there was a delay in signal display around 20s (in OpenVibe Designer using the signal display box). Also, in the OpenVibe Acquisition Server, I tried selecting OpenBCI as the Driver, but I'm using Ganglion (4 electrodes) so I think that is why it won't recognize the port (since the default are 8 or 16 electrodes). Does anyone have an idea why the LSL protocol might be a problem, and how to fix it?
OpenVibe version: 2.2.0 (32bit)
OpenBCI_GUI version: tried with many versions, the 32bit won't even start the LSL! (Windows 10)
Thank you in advance,
Jelena ![]()
Comments
There are no problems with LSL using GUI 64-bit and OpenVibe 64-bit. Also, I have tested this many times without a delay. Finally, the OpenBCI driver in OpenVibe is for Cyton only and is maintained by OpenVibe.
Thank you for the advice! However, the problem is still there. I tried using both 64bit but there is still a huge delay (around 20 s). Could there be another explanation to why this is happening? Maybe the openvibe acq server? Again, thank you for replying.
Jelena, hi. Can you mention the computer you are using, I'm confused about your 32 bit comments. I assume your computer is 64 bit, Windows 10. Do you have another computer or OS there you can try, to eliminate the possibility the problem is with your computer instead of OpenBCI or OpenViBE / LSL?
Hello! Yes, the computer is 64 bit, windows 10. I have tried using 6 computers in total, all are Windows 10 or 7. I am using Openvibe and OpenBCI because the LSL functioned just fine in june this year, and it still does on that same laptop (that I cannot use at this time). I tried downloading the older version of openBCI GUI that is on that laptop, bit it's no use. So I really can't tell what is the source of this problem. Maybe that the LSL is marked "unstable" in the Openvibe acq server has something to do with it..
"the LSL functioned just fine in june this year, and it still does on that same laptop (that I cannot use at this time)."
Can you describe the system that works correctly? : 32/64 bit, OS, versions of GUI and OpenViBE? Can you mention what dongle you are using; only one supported presently is BLED112.
The dongle that is used is BLED112,
OS is Windows 10 (64 bit),
Openvibe version is 2.2.0 (32 bit),
GUI version is v4.1.3-beta.1.
I have replicated these conditions on the same system (Windows 10, 64 bit) but without using the GUI 32 bit because it won't start the LSL protocol (the GUI just freezes).
Please try GUI 4.1.6 64bit and OpenVibe 64bit.
I have tried that, as you previously suggested, but there was still a delay around 20s.
Cool, but can you share some proof please? Screenshot? Screen recording?
Other users are claiming this 20s delay, and I have never seen this problem with extensive testing.
There is already an issue for this on Github that points to a forum thread that this has now become a duplicate of: https://github.com/OpenBCI/OpenBCI_GUI/issues/595
All users experiencing this problem (if it exists) have to have something in common... We need more information on this.
Jelena, as per Richard's issue link, could you try a test with Matlab to see if the delay is present there? As you mentioned before, this could be some obscure issue with OpenViBE Acquisition Server.
Or if Matlab is not available, there are other ways to consume an LSL stream, as shown, in various languages including Python,
https://github.com/sccn/labstreaminglayer/wiki/ExampleCode
Here are the Python 3 test scripts used to develop GUI 4.1.6 and fix multiple LSL streams
:
https://github.com/OpenBCI/OpenBCI_GUI/tree/master/Networking-Test-Kit/LSL
Will need to do
pip install pylslfirst.Okay, so here are the results- tested it in Python and there was no delay. So, I would say that there is a problem in Openvibe. Here is a screenshot for proof of delay (if this is what you had in mind):
Thank you for your help!
Jelena, can you post the LSL delay issue on the OpenViBE forum? There might be some adjustment or workaround that fixes the delay.
Regards, William
That link is, http://openvibe.inria.fr/forum/
I have, but nobody has replied yet. If somebody solves the problem there, I will post it here too.
I just looked at your post,
http://openvibe.inria.fr/forum/viewtopic.php?f=5&t=10090
But the title states: "OpenBCI Ganglion + Openvibe LSL protocol". This is NOT very descriptive and may not draw attention of the OpenViBE developer who understands what you are getting at. My suggestion is to edit the title to something like: "Serious bug in OpenViBE AS (LSL) with OpenBCI stream output: 20 second delay"
You also need to make clear in that post that the delay is GONE when receiving the stream in Python. THUS the error must be in the Acquisition Server, by deduction.
Thank you for the help, I will edit my post there!
Hello!
Sorry, me again.
A new problem occured with Python. The delay is very much present when using LSL protocol for EEG data. With the Accelerometer the problem is not there at all! I haven't figured it out until I visualized the EEG data in Python. I apologize for the false information.
Your earlier comment was: "Okay, so here are the results- tested it in Python and there was no delay. So, I would say that there is a problem in Openvibe." So it looks like there is an issue with your Python setup, since it worked at one time.
It worked with the Accelerometer, since I tested the LSL with that data (so that I could compare the values of the x,y,z axis). Again, I apologize for the false info.
If the test programs that Richard @retiutut mentioned,
https://github.com/OpenBCI/OpenBCI_GUI/tree/master/Networking-Test-Kit/LSL
Are delaying the EEG samples, but not Accelerometer samples, it seems very odd. Because the EEG data and Accel data are interleaved and ride together in the Bluetooth radio packets. In fact these test programs have no mention of the Accel stream and are only printing raw values.
What / where are your Python test programs that are failing? Are you certain that your calls on LSL functions conform to the LSL documentation? Do these test programs at the link above show the delay?
Yes, that is the test program that I used (lslStreamTest.py) - I haven't changed a thing. Here are screen recordings of the Accelerometer data and EEG data (I plotted the EEG also, so that the delay was more visible, but with the lslStreamTest.py script there is still a delay - around 20 seconds).
I'd like to hear what Richard @retiutut thinks, since he regularly uses these Python programs to confirm that GUI LSL is working as expected.
I do see a problem with lag in the EEG plotting example. You are definitely NOT using lslStreamTest.py to get TimeSeries data!!! Come on now! You can't say "I'm using X code" and then use something else and wonder why it doesn't work!
Looks to me like a problem with your Python code. Here's why...
This is why I have a hard time believing it's a problem with the GUI, and I have high quality proof. These are the same results I've already shared. No lag.
I am not using the lslStreamTest.py for plotting, and I am not trying to trick you. I just have a problem and asked for help, nothing else. I am using that EXACT same script (lslStreamTest.py https://github.com/OpenBCI/OpenBCI_GUI/tree/master/Networking-Test-Kit/LSL) for printing the values (not plotting, obviously) !!!
I am sorry if it's not high quality, I will send "proof" again when I get the chance, with the script fully visible. I plotted the EEG just so I can show the delay more clearly. I believe that you don't have the problem, I just asked if anybody knew what could be making a problem...
And when I plot the Accelerometer values, they do not show the delay (with the same script I am using to plot EEG - also, will send proof).
Here are my results. I also noticed that you have 8 channels in the video, so I have to mention again I'm using Ganglion (4 electrodes). Also, I tried stopping the data stream as you showed above, and the stream does stop immediately but the problem is still there - the values are delayed by 20 s. If you look at the printed values for EEG you will notice bigger amplitudes being printed 20 seconds later (instead of being the range (-10,10) they are above 200).
Sorry for the quality, here are the videos again (I cannot post videos here and the gifs just won't cooperate).
https://drive.google.com/drive/folders/1XybmXr-vGJp_u1yeKpMlh7BTOUVCgkv_?usp=sharing
Can you please do exactly what I did in my recording? I'm not interested in looking at a stream of numbers to tell the difference! It's very obvious in my recording that there is no delay streaming time series data.
As i said, when I stop streaming data in the OpenBCI GUI, there is no delay (just like in your case). So that is not the problem. The values that you are talking about are the problem! If the values that I get in Python are delayed by 20 seconds, I cant do anything with that data. I think we can agree on that.
The point I made with my screen recording is that when the data stops in the GUI, the data stops in Python.
Please make a recording just like mine and share it:
* Start GUI in synthetic mode
* Stream TimeSeries over LSL
* Start screen recording
* Start data stream
* Stop data stream
* Start data stream
* Stop data stream
* Stop screen recording
I don't want to see data just streaming with a delay. I want to see the data stream stopping in 2 applications at the same time. If they start/stop at the same time, there is no lag!
Starting to get frustrated with people claiming there is an LSL delay without trying to replicate my results! I get the same results over and over across different applications.
The code is almost exactly the same for streaming all data types over LSL. So there is no reason, from a coding standpoint, why one data type would have a lag and another would not. Think about it!!!