OpenViBE forum

The OpenViBE community
It is currently Thu Sep 21, 2017 7:06 am

All times are UTC

Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 
Author Message
PostPosted: Wed Apr 14, 2010 10:00 pm 
Site Admin

Joined: Fri Sep 01, 2006 3:39 pm
Posts: 645
New release of OpenViBE 0.6.0 Spring edition is now available for download at :

This release as been delayed because of a bug in the acquisition server. More information about this bug can be found on the dedicated forum topic in the NEWS section.

=== Overview =========================================

OpenViBE is an opensource platform that enables to design, test and use Brain-Computer Interfaces (BCI). Broadly speaking, OpenViBE can be used in many real-time Neuroscience applications.

The OpenViBE platform stands out for its high modularity. It addresses the needs of different types of users (programmers and non-programmers) and proposes a user-friendly graphical language which allows non-programmers to design a BCI without writing a single line of code.

OpenViBE is portable, independent of hardware or software targets, can run under Windows and Linux and is entirely based on free and open-source software. OpenViBE is compatible with MATLAB programming.

OpenViBE comes with preconfigured scenarios and runs already existing applications such as :
    * BCI based on motor imagery
    * P300 speller
    * Neurofeedback
    * Real-time visualization of brain activity in 2D or 3D

OpenViBE is available under the terms of the LGPL-v2+. The whole software is developed in C++. It consists of a set of software modules that can be integrated easily and efficiently to design BCI applications such as for Virtual Reality interaction.

=== Where to get more information ====================

If you want more details, check these links :


Quick introduction video :

Software download :

One-hour training session video :

Screenshots and videos :

=== What changed since 0.5.0 ? =======================

In this new release, you will find the following modifiactions (+ for adds, * for modifications, - for removes) :

    + Lucie Daubigney contributed a new driver : g.Tec's gMobiLab+ acquisition device for Linux
    + We added a new driver : Micromed SD LTM (through SystemPlus Evolution)
    + We added impedance check to the drivers that could support it
    + We updated the sample scenarios
    + We added a Confusion Matrix computation box
    + We added a Matrix Display box
    + We added a Lua stimulation box
    + We reenabled VR demos as default
    * We enhanced the visuals of the VR demos and added a few stats to make the experience more entertaining
    * We refactored the acquisition server so the server itself runs in a separate thread for better performances
    * We corrected some bugs on the acquisition server that caused desynchronisations
    * We moved to Ogre 1.7 for 3D display
    * We moved to Boost 1.41
    * We updated the online documentation and tutorials
    * We updated many documentation pages
    * We fixed lots of bugs !
    - We removed OpenMASK / OBT dependency

=== What's coming in the next release(s) =============

Here is a snapshot of what we are currently doing and what you can expect from the next release(s) :

    + A Neuroscan acquisition driver
    + A MitsarEEG acquisition driver
    + An EGI acquisition driver
    + More tools dedicated to plugins developpers (base classes, code generators etc...)
    + More tools dedicated to authors / designer users
    + A more general matrix operations box

=== Closing words ====================================

We want to thank Lucie Daubigney for her contribution to the g.Mobilab+ driver.
Feel free to join us and to contribute as Lucie and
others are doing... !

Looking forward to hearing your feedback, we hope you'll enjoy working with OpenViBE as we do.

Best regards,
The OpenViBE consortium

Contact :
Project Leader : Anatole Lécuyer, INRIA (
Lead Software Engineer : Yann Renard, INRIA (

CTO at Mensia Technologies | Image my blog | Image my tweets | Image my linkedin

Reply with quote  
PostPosted: Wed Apr 14, 2010 10:00 pm 
Site Admin

Joined: Fri Sep 01, 2006 3:39 pm
Posts: 645
I will post a message about the acquisition server modifications soon... hopefully tomorrow. Stay tuned.


CTO at Mensia Technologies | Image my blog | Image my tweets | Image my linkedin

Reply with quote  
PostPosted: Fri Apr 16, 2010 12:00 pm 
Site Admin

Joined: Fri Sep 01, 2006 3:39 pm
Posts: 645
Ok, as promised, I will post a few words about the acquisition server modifications we did for 0.6.0...

To give you a more detailed view of what lead us to those modifications, let's jump back in time around January, when Dieter posted his nice video about controlling a robotic arm with OpenViBE. Back then, he bought a new TMSi Refa32 device which did not work as expected with the Nexus32 drivers he used for his first device. At the same time, Baptiste was working on a TMSi Refa32 dedicated driver and we hoped that would solve his problems. Unfortunately, it did not ; it seemed that the P300 peeks were received too late, suggesting some samples had been lost in the pipeline. We already had such issue with the Nexus32 driver which sometimes did not send enough samples, and sometimes sent too many samples. We then had to monitor the number of samples over time to be sure that the average number of received samples over time did not move too far of the actual sampling rate.

Based on those observations, we decided to monitor what was received from all the acquisition drivers and compare it to the actual promised sampling rate... And we observed some problems on almost all the drivers. The gravity (e.g. number of lost samples) and the conditions in which those problem occurred was variable from a driver to another. But still, this had to be solved before the release. We identified three reasons why the number of samples did not match the promised sampling rate :
    1. the driver flushes a big number of buffered samples at start time
    2. GUI actions (e.g. move the acquisition server window) causes the driver to miss some samples
    3. A small jitter is occurring over time because the hardware clock of the device is not perfectly synced with the hardware clock of the computer (e.g. the device believes it sends samples at 512Hz but the computer receives it at 512.1Hz. After 10 seconds, there is 1 more sample received and after 2 minutes, it is 12 more samples received, etc)

Case number 1 is not really an issue. Indeed, the designer usually connects to the acquisition server after the buffer is flushed. Anyway, the driver should take care of this, flushing whatever buffer the used API has before starting to send those samples to the acquisition server.

Case number 2 is potentially a serious issue. The acquisition server being single threaded and the loop function being called only on idle, as soon as you click on the title bar of the acquisition server, there is no more updates from the driver. This can result in potential sample loss. This is not a typical use of the acquisition server, we usually don't manipulate its GUI while acquiring signal. But still, if someone moved the window for a reason, the whole data arriving in the designer would be misdated resulting in severe syncing issues. To correct this, we moved all the non-GUI related things in a separate standalone thread. Good to notice that such architecture was mentionned in the g.Tec API documentation.

Case number 3 can be an issue for long runs, and there is no ideal solution to solve it on the driver side. Inserting / removing some samples to keep the synchronization as it's been done in the Nexus32 driver should be acceptable as it only happens occasionally.

For the future of driver developments, it is important that each driver developer keeps in mind to send a number of samples as close as possible of the promised sampling rate (that means flush whatever buffer at start time, does not lose samples from the device etc...). We included a few functions in the driver context to monitor the jittering. In order to solve case number 3, we propose a function to correct the jittering (again, this jitter correction should be as small as possible, only related to hardware clocks not perfectly synced) and a function to get a hint from the acquisition server as the number of samples that should be corrected... Additionally, if a driver does not send the correct number of samples regarding the promised sampling rate, a console message will be displayed to request a bug report.

As a conclusion, the drivers currently included in OpenViBE should now send the correct number of samples over time. We hope that the proposed functions to { monitor / correct / get hint for correcting } the jitter will help in better device integration.

Do not hesitate to contact us on any issue you would find with those updates.
The driver development tutorial will be updated soon...

Best regards,

CTO at Mensia Technologies | Image my blog | Image my tweets | Image my linkedin

Reply with quote  
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 3 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Americanized by Maël Soucaze.