OpenBCI_Python: unreliable Linux / Mac acquisition?
Hello,
I am trying to get live visualization of OpenBCI data
(8 bit board) going with Python and matplotlib. The mid term goal is to do some simple
Neurofeedback training.
Currently im am using a Linux/Ubuntu PC for development, but i have observed the same issue on OS X.
My
problem is that i can not get a smooth data stream from the OpenBCI.
Occasionally, there seems to be an extra, or simply wrong byte, which
confuses the parser (in OpenBCIBoard._read_serial_binary).
This leads to the packet IDs not being reliable. This problem does not
correlate with distance between the OpenBCI and the bluetooth dongle, so
i hope this is not simply caused by packet loss.
I
attached a plot of incoming packet the IDs (the lower plot of the
attached image), which should be a perfect sawtooth in theory. With this
kind of packet loss, signal processing becomes a lot harder. Also in
theory, since the OpenBCI samples at 250 Hz, and the IDs count up to
255, a single tooth should take roughly one second. Since it seems much
slower, i highly doubt that i am receiving usable data.
Here is a log of running user.py, which exhibits the problem:
I am trying to get live visualization of OpenBCI data
(8 bit board) going with Python and matplotlib. The mid term goal is to do some simple
Neurofeedback training.
Currently im am using a Linux/Ubuntu PC for development, but i have observed the same issue on OS X.
My
problem is that i can not get a smooth data stream from the OpenBCI.
Occasionally, there seems to be an extra, or simply wrong byte, which
confuses the parser (in OpenBCIBoard._read_serial_binary).
This leads to the packet IDs not being reliable. This problem does not
correlate with distance between the OpenBCI and the bluetooth dongle, so
i hope this is not simply caused by packet loss.
I
attached a plot of incoming packet the IDs (the lower plot of the
attached image), which should be a perfect sawtooth in theory. With this
kind of packet loss, signal processing becomes a lot harder. Also in
theory, since the OpenBCI samples at 250 Hz, and the IDs count up to
255, a single tooth should take roughly one second. Since it seems much
slower, i highly doubt that i am receiving usable data.
Here is a log of running user.py, which exhibits the problem:
$ python user.py -p /dev/ttyUSB0 --add csv_collect
USER.py
------------SETTINGS-------------
Notch filtering: True
-------INSTANTIATING BOARD-------
Connecting to /dev/ttyUSB0
Serial established...
No daisy: 8 EEG channels and 3 AUX channels at 250.0 Hz.
------------PLUGINS--------------
Found plugins: [ sample_rate ] [ print ] [ streamer_tcp ] [ udp_server ] [ visualize ] [ csv_collect ]
Activating [ csv_collect ] plugin...
Will export CSV to: 2015-4-23_20-11-15.csv
Plugin [ csv_collect ] added to the list
--------------INFO---------------
User serial interface enabled...
View command map at http://docs.openbci.com.
Type /start to run -- and /stop before issuing new commands afterwards.
Type /exit to exit.
Board outputs are automatically printed as:
% message
$$$ signals end of message
-------------BEGIN---------------
--> /start
--> Warning: Skipped 158 bytes before start found
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <168>
Warning: Warning: Unexpected END_BYTE found <176> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <204> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <142> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <84> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <119> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <4> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <77> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <49> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <148> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <67> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <28> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <132> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <161> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <160> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <184>
Warning: Warning: Unexpected END_BYTE found <0> instead of <192>, discarted packet with id <205>
Comments
Does the board run ok with OpenBCI_GUI or BrainBay? I'll mention Jeremy @jfrey and Rodrigo @Rceballos98 in case they might have comments.
William
It seemed to work ok with BrainBay, allthough i only ran it on Windows, not on Linux, which might behave differently.
The parsing code of the BrainBay driver looks a bit more robust than that of OpenBCI_Python, but i do not remember that BrainBay reported any sync losses when i tested it.
I'll try BrainBay on WINE too, maybe the problem is related to the OS Layer, or the FTDI drivers?
What i found weird is that i found nobody with the same problem, so either nobody actually uses the OpenBCI_Python interface, or something is wrong with my hardware.
Jonathan
On BrainBay, the sync errors are at the bottom of the window in a status area labeled "(__ lost)". If that counter is relatively stable (only increments rarely), then all packets are being received ok. So it does sound like your board is working ok, hardware wise.
So it might be instructive to try your Python test on Windows as well. I assume you've adjusted the FTDI driver Latency Timer on Windows. Not actually sure how that is done on Linux; possibly just tries to "do the right thing".
But your other point I think is also true, the community engaging the OpenBCI_Python is gradually getting more users. Thanks for your patience.
William
PS I think Jeremy @jfrey might comment when he has more free time over the weekend. The '@' references send email notification to those mentioned.
Just checking if you had had any luck with getting the python to work on your linux machine? Did you figure out what might have been causing these errors (lower battery, etc)?
The Python bindings work fine on my Macbook, so i
am now using Windows for development (Since the FTDI drivers seem to
occasionally freeze my system on OS X).
I have yet to test the setup on a different Linux machine, so it theoretically still be a problem on the host side.
The FTDI drivers are still a mess. We are trying hard to get a decent fix for Yosemite but in the end we need STDI representatives to collaborate. If you would like to join in on that fun or try some of the hacky fixes people have found to solve the issue temporarily you should check out this forum: