OpenViBE v1.0 now supports OpenBCI

edited March 2015 in Software
[Update 2015-3-20: A v1.0 direct Windows binary installer is now available to download from the OpenViBE site, see the March 20 entry below. Linux users should also download the git source from the main INRIA site and build from that.]


Last couple days I tried to develop an integrated driver within OpenViBE. I say "try" because although it *does* seem to work, now I'd need others to try out the implementation. And I'd need others *quickly* because the 1.0 release is soon (like "by-the-end-of-the-week" soon normally). OpenViBE doesn't do "release early, release often", and 1.0 could be a good milestone to kick-off new OpenBCI owners.

The branch is available in the official repository: 

git clone -b wip-jfrey-openbci-driver

To build OpenViBE there's neat scripts the "script" folder. On Windows, run "win32-install_dependencies.exe" and then "win32-build.cmd". On Linux it's almost the same, "linux-install_dependencies" and "linux-build" -- see

When the compilation is done, "dist" folder is populated with the binaries you need -- basically "openvibe-acquisition-server" to acquire data and "openvibe-designer" to use them. If

At the moment I tested with (K)Ubuntu 13.10 & 14.04 + Windows 7, 64bit for all. Chipkit board, with and without daisy module attached. If it's your first time with openvibe, try to use a fake signal such as "Generic Oscillator" to make sure that the installation is working -- I'm here to sell my own stuff, I don't do OpenViBE support (yet) :D

Please test, any feedback -- success, bug, failure, typo, next lottery numbers -- is very welcomed. Thx :)


  • edited March 2015
    Jeremy, I wonder if you would find more testers if you made available zips or tars of the compiled distributions. So that the source download and build steps could be bypassed. Thus saving considerable time in setup.

    And, is it possible that folks just need to download the Acquisition Server alone, containing your new driver? In other words all they need is the new A.S. binary and could they use all the existing OpenViBE downloads from

    Or does your new A.S. driver depend on the latest sources for all of OpenViBE?

    One other question, for those with Macintosh, what is the best strategy? Partitioning and dual booting Linux may be more than most Mac users would want to contend with. Could it run under VirtualBox?

    Regards, William

    PS the related previous thread on the P300 Speller,

  • brainbrain Canada
    edited February 2015
    @jfrey I built your branch on Ubuntu 14.04 LTS, and tested it with an 8 Channel 32bit OpenBCI. It built painlessly and I got data from the board without any errors :) I didn’t manage to test it with actual EEG signals today (I just used the accelerometer data and touched the pins to check the channels) but I hope to do that soon.

    It’d be very cool to have this in v1.0. I guess I should have waited a few days rather spending all that time getting the Python link working :)

    Great work,
  • edited February 2015
    @brain , would you mind uploading a tar or zip of your OpenViBE Ubuntu binary tree? 14.04 LTS sounds like the way to go. I'll set that up with VirtualBox.
  • brainbrain Canada
    edited February 2015
    @wjcroft @jfrey

    Sorry, that was a typo: I’m running Ubuntu 14.04. Here’s a .zip of the dist directory created by my build:
  • @brain Great, thanks a lot :)) You don't have to regret your time spent with python, at the moment it is still the one solution that I know for sure is working. Besides, even a few days ago it wasn't obvious at all that a specific driver would appear anytime soon; it was only on last Sunday that I had the sudden inspiration (and urge!) to challenge OpenViBE source code.

    As for the "build, zip and send", I'm not sure it'll work. I've already tried this in the past, to exchange an OpenViBE installation between computers, and for this to work, if I remember correctly, the destination folder must have exactly the same path, eg: /home/doe/openvibe-git/dist on both computers. + of course compatible external libs (don't try different distributions or architectures). And the dist folder also is HUGE, lot's of dependencies are fetch and compiled. Hopefully after the 1.0 release the installation process on linux will be smoother (I have to take a look at how to package .deb archives).

    The git AS may be able to work with previous version of OpenViBE, and I have no idea of the best solution for mac users. I guess the virtual box solution is the one. If you do manage to launch on mac an OpenViBE that was compiled elsewhere, it'd be a victory on its own :D
  • edited February 2015
    Well I did manage to get the started in a VirtualBox'ed Ubuntu 14.04 guest on a Macintosh host. Just symbolic linking @brain 's home directory to mine solved the compiled in paths. BUT -- there are a ton of libraries installed as a part of the build process (such as Ogre 3D, ...) And these were not included in the zip. I guess they stashed those in /usr/local/lib or somesuch.

    As you say, OpenViBE should certainly have some kind of installer or 'portable' version with all dependencies in a folder hierarchy. (As the portable USB stick apps use.)

    I'll probably try a build later...

  • Usually the first installation could be tricky, in the future there will be way less dependencies (even if it produce nice geekish examples, it's not that obvious that ogre is needed to do EEG).
  • successfully built  on (L)Ubuntu 14.04 and (minimalist) trials whith 8 Channel 32bit OpenBCI

    well done !
  • Thanks for your feedback! I also check with actual EEG data that the driver was working on my side -- not only the obvious alpha activity but also some motor imagery -- and the code should be included for the next release :) I just hope a nasty bug did not slip through in my ultimate commits...
  • You know the differences between V2 and V3 boards and if the driver is backwards compatible? 

    p.s. what is your average classification performance during online control with M.I.?

  • I have no idea regarding V2 protocol... I don't think it is the same (the v3 has restrictions regarding radio packets), but it's a wild guess.

    The classification performance given by OpenViBE for MI with right hand/left hand was poor, around 75%, but I did not spend much time to train and test, I only ran the scenario twice (it was getting late!). Besides, I'm not sure you could really take this value into account -- only 40 trials and I think there is a bias because of how CSP is computed, I will have to double check for the latter info.
  • edited March 2015
    V1 and V2 were the Arduino shields using a real (or usb) serial port. V3 is the RFduino based board and dongle: (both 8 and 32 bit boards).

    Yes the protocol changed in V3. Both endian-ness and sample size (from 32 to 24 bits). Also V3 added the accel. channels.

    There are only a very few of the V1 and V2 boards out there, so having "compatibility mode" on the laptop makes less sense. It's also possible to revise / update the firmware if you have access to a V2 board, so that it sends the same protocol format as V3. Although you would have to do some cut/pasting of the source yourself.
  • edited March 2015
    Jeremy has a version running on Raspberry Pi(!)


    Jeremy, can you mention which of the 'standard' box functions in categories such as Signal Processing / Visualization, etc. -- are available in the Pi version? Is it just a matter of how many CPU cycles are available and memory consumed? So this should work in basically any embedded Linux environment? Recommended minimums GHz, RAM, cores, etc.

  • edited March 2015
    I've not done much testing; every boxes is available but I strongly suspect not all of them will work flawlessly. Raspberry Pi is not officially supported, if OpenViBE launches it's just a "side-effect" of a good code.

    The limiting factor is the amount of RAM -- I left 16MO for the GPU in the "memory split" option -- and of course the CPU. For this screenshot I only used a "temporal filter", a "signal display" and box that exports signals as LSL, and the acquisition server was already starting to lag. Both the acquisition server and the designer were competing for the one core...

    Although with the Raspberry Pi 2 and its quad core CPU it'll be another story, it may already be possible to speed-up the designer (the part of OpenViBE that processes signals) by *not* starting the X server. The designer has flags that deactivate  graphics -- and then it can work through ssh -- but from the messages that are printed in stdout I infer that even in this case gtk is not completely disabled, hence there is still room for optimizations.

    I don't think the dev team has resources to spend on this specific platform -- not really the targeted public :D --  but if some people are interested by a Raspberry Pi version of OpenViBE and want to hack the code accordingly, I'm sure they will welcome the changes as it will profit the whole project.

    BTW, the only things I modified in order to compile the code was to comment out a buggy assertion and to prevent a contributed application to be included in the process (missing perm.h file??); apart from that it's a fresh install of Raspbian.

  • Jeremy announced on his Twitter feed that INRIA has now released OpenViBE 1.0 including Jeremy's OpenBCI driver(!)

    Very cool, thanks for getting us into this latest release. Downloadable installer at,


    I installed it on my Windows machine, and it seems to work fine. A couple questions though.

    Even with the simplest setup of only the Acquisition client (Generic Oscillator) going to Signal Display, my Process Explorer (Windows CPU process monitor) shows the OpenViBE Designer as using 98% of the cpu. This old Windows machine of mine just has a single core. Does OpenViBE assume multicores?

    I then setup another simple scenario that took the OpenBCI acquisition, through a Temporal Filter (.5 to 40 hz) and then to Signal Display and (FFT to Spectrogram). This looked as expected, and...  The spectrogram scale looks somewhat course with only about 6 bands shown from 0 to 40 hz. It looks like each band is about 8 hz. Is there a way to get finer resolution? I looked at the configurations for all the boxes, and didnt see anything obvious. I admit I'm a complete novice with OpenViBE. :-)

    Thanks again for making this amazing BCI tool available to our community.


  • Thanks (again!) for cross-posting the information on the forum, twitter is new to me and I tend to forget about the old ways ;)

    I'm glad the signal acquisition is working in the final release, I have to admit that I did not test the driver once the other devs made their final commits :D

    The CPU consumption is normal, OpenViBE monopolizes a whole core when it's running -- I guess it want to make sure it has sufficient resources. You can check that your computer can handle the processing by looking at the CPU load indicator in the designer window, in the bottom right part. Also, if your computer is too slow, you will see warning messages popping in the console, something like "...2 seconds late...". As long as there is no such message an the CPU load in OpenViBE is below 100%, you're good :)

    As for the FFT, the number of slices depends on the chunk size of the signal and to the corresponding time period that it represents.  Indeed, OpenViBE works on "chunks", the number of values per channel that are processed altogether. Eg: you set the chunk size in the acquisition server to "32" and your signal is sampled at 250Hz. So each chunk will represent 1/250*32 = 0.128s.

    The longer the chunk (in time) the more slices you got in the power spectrum and time-frequency map display. It's tedious to compute... fortunately you got a box called "time based epoching" that let you aggregate chunks based on time. Just increase the epoch size (eg, 1s) and your FFT will have more details.

    OK, it's not that clear, play with "Matrix Display", "Signal average" and "Time based epoching" to understand how the values are passed and transformed from one box to the other. There is a "time-frequency-map" scenario that comes with openvibe (dist/share/openvibe/scenarios/box-tutorials).

    I do not use often the FFT analysis, so maybe I'm missing something here, I guess OpenViBE website contains tutorials and help pages that are more detailed and accurate.
  • edited April 2015
    Hi Guys,

    Can someone share a dataset from OpenVibe+OpenBCI from a Motor-Imagery training?

  • Hello, 

    I'm trying to use openBCI with openViBE, thanks a lot for the driver !
    but the signal look strange, and I didn,t understood well how is made the measurment when i use openbci in openvibe.
    the signal I can see is measure between an electrode and o "SRB" or between N and P of th input ? what about the GND ?
    how can i choose this ? 
    I saw the "send comand on init" and i try to send as i found here. it's not really clear for me....
    I would to record two electrods with a reference near the ear, 
    what should i do...please ?

    thanks a lot 

  • Youpi, have you first gone through the tutorial steps with the OpenBCI_GUI first? That explains use of Bias, SRB2, etc.

  • yes, this part ialready read and understand, so my question would be more clear :
    When I use OpenBci in openvibe what is the type of measurment by default ? and how to easily change it ?
  • Hello,

    The measurements by default... are the one you get when you switch-on the board, ie SRB2 and all channels activated. Use the codes described here to set other parameters via the driver properties: ; eg "345678" will disable channels 3-8.

    You can try first these codes "live" using the Python wrapper and LSL streamer -- at the moment you have to disconnect / reconnect the OpenViBE acquisiton server each time you want to set new parameters.
  • thanks a lot !
    i'll see this more in details ! 

  • @wjcroft, I got an ubuntu VM guest on my mac host to build and connect to the OBCI. However, when I actually "play" the acquisition server it consumes the whole 4 cores with 4GB RAM that I gave it to the point that the VM freezes over and is useless until I disconnect the board.

    Did you ever get yours to work?
  • Rodrigo, hi.

    The March 20 post above was on my native Windows machine with v1.0. Ran fine there. I did try initially fooling around with OpenViBE (pre v1) on Mac under VirtualBox / Ubuntu (Feb 26 post above). But there was no installer at the time; failed.

    Can you just boot natively into Ubuntu? Is the OpenBCI_GUI running ok with your VM Ubuntu? I believe Jeremy @jfrey has tested v1.0 both in Windows and Ubuntu. The OpenViBE GUI interface does pretty much eat one core though; see his comments above on March 21. The multicore usage in your VM case might be some artifact of the VM emulation.

  • Hi William,

    Yes, I have gotten it to work on native ubuntu and windows, I was trying to find an easier alternative for Mac users that might not go as far as to dual boot to use the software.
    I'll keep the forum posted on any developments.

  • Might also experiment with the different virtual packages, for example Xen, Virtualbox, Parallels, etc. At least the free ones.

    Microsoft also has free VirtualBox images of Windows 7, 8.1, etc. that will run without nagging for I think 6 months until you need to refresh. So it could be that Windows under VirtualBox has less kinks than Ubuntu.

  • Hi William,
    Forgot to reply to this. Thanks for the tip!
    For anyone interested in a step by step tutorial about using a Win VM on mac to run OBCI + OpenVibe, check out this tutorial: tools/OpenViBE

Leave a Comment