The following drivers have been integrated into OpenViBE release 0.15.0.

Manufacturer	Amplifier	Driver Name	OS	Status	Officially Supported
ANT	Neuro ASALAB EEG / ERP amplifier	Either MindMedia Nexus32B or TMSi drivers		Has been reported to work	No
	Others TMSi derived devices	Either MindMedia Nexus32B or TMSi drivers		Untested	No
BrainMaster	Atlantis	Brainmaster Atlantis and Discovery		Stable	Community : Mensia Technologies
	Discovery	Brainmaster Atlantis and Discovery		Stable	Community : Mensia Technologies
Brain Products	V-Amp	Brain Products V-Amp		Stable	No
	actiCHamp	Brain Products actiCHamp		Stable	Yes, contact Mensia Technologies
	QuickAmp	Either MindMedia Nexus32B or TMSi drivers		Has been reported to work	No
	BrainAmp Series	Brain Products BrainAmp Series		Stable	Community : Yann Renard
	All	Brain Products BrainAmp Standard (through BrainVision Recorder)		Stable	Community : Emmanuel Maby (INSERM) Pierre-Emmanuel Aguera (INSERM)
CTF/VSM	MEG	CTF/VSM MEG		Unstable	Community : Emmanuel Maby (INSERM) Pierre-Emmanuel Aguera (INSERM)
EGI	Net Amps 300	EGI Net Amps 300 (through AmpServer)		Unstable	Community
Emotiv	EPOC	Emotiv EPOC		Stable	Yes
gTec	gUSBamp	g.Tec gUSBamp		Stable(multi amp missing)	Yes
	gMobilab+	gTec gMOBIlab+		Stable	Community : Lucie Daubigney (Supelec)
Micromed	SD LTM	Micromed SD LTM (through SystemPlus Evolution)		Stable	Yes
MindMedia	NeXus32	MindMedia Nexus32B		Stable	Yes
Neurosky	Mindset	NeuroSky MindSet (MindWave Mobile since SVN r3590 / unreleased 0.16.0)		Stable	Yes
OpenEEG	MonolithEEG	OpenEEG Modular EEG P2		Stable	Community : Christoph Veigl (University of Applied Sciences Technikum Wien) Yann Renard
	ModularEEG	OpenEEG Modular EEG P2		Stable	Community : Christoph Veigl (University of Applied Sciences Technikum Wien) Yann Renard
TMSi	Porti32	Either MindMedia Nexus32B or TMSi drivers		Stable	Yes
	Refa32	Either MindMedia Nexus32B or TMSi drivers		Stable	No
	Others devices	Either MindMedia Nexus32B or TMSi drivers		Untested	No

Beta drivers

These drivers are currently being integrated or does not comply with, some of them can be found in the current Acquisition Server branches in the SVN, others can be found in the deprecated branches folder (checkout the SVN at address svn://scm.gforge.inria.fr/svn/openvibe/deprecated-branches). To use them, you must build the corresponding branch. If the driver is in a deprecated folder, you first have to put it manually in your SVN local repository under openvibe-application/acquisition-server/branches/.

Manufacturer	Amplifier	Driver Name	OS	Status	Officially supported
Mitsar	EEG 202	Mitsar EEG 202		Unstable	Community : Guillaume Lio (GipsaLab)
Neuroscan	SynAmps2	Neuroscan SynAmps2 (through Scan 4.3)		Unstable	Community : David White (Swinburne University of Technology) This driver has been moved to the deprecated branches SVN folder (openvibe-applications-acquisition-server-wip-neuroscan)

In the newer versions of openvibe we have updated the CMake dependency to 2.8.7. Newer build system also relies on the GNUInstallDirs CMake include file, which is not present in CMake 2.8.4 and earlier. If you wish to compile latest openvibe on Fedora 14 you will need this file.

You can download the file (distributed under the OSI-approved BSD license) here: GNUInstallDirs

The box algorithm

The box algorithm is a key component of the platform. It consists of a “black box” in charge of a fraction of the whole processing pipeline, which exposes inputs and outputs to other box algorithms. Boxes are notified on clock ticks and upon input data and message arrival. The behavior of a box can be adapted to the needs of each algorithm (for instance, acquisition algorithms typically react to clock signals whereas processing algorithms typically react to input arrival). The characteristics and constraints that are common to all box algorithms include reasonable granularity to allow quick software components rearrangement. Newly developed box algorithms are immediately available to the user thanks to the plugin system (see section The plug-ins).

The kernel

The kernel (see OpenViBE::Kernel::IKernelContext) provides global services to applications through several managers, each of them providing a set of specialized services. Virtually any manager can be added to the kernel in order to extend its services. The most significant managers of the platform are:

The scenario manager (see OpenViBE::Kernel::IScenarioManager) helps creating and configuring scenarios. After a scenario is created, it can instantiate new box algorithms, change their settings and connect boxes together using communication links. The scenario manager is designed to edit any number of scenarios at once, allowing an application to handle multiple scenarios simultaneously. The designer authoring tool takes advantage of this.

The player manager (see OpenViBE::Kernel::IPlayerManager) provides an easy to use interface in order to build and configure a runtime session. For this, the manager handles a collection of players, each one managing several boxes, as described in the scenario it has to run. Each of these box rely on a plug-in box algorithm to perform its tasks.

The visualization manager (see OpenViBE::Kernel::IVisualisationManager) is responsible for displaying 2D or 3D graphical information and dispatching it in the correct place. Indeed, multiple visualization windows may be used. The windows arrangement in space is done by the visualization manager at editing time, thanks to the designer application, and saved to a file. Basic signal display windows are provided with a 2D rendering context (see Figure fig-display-widgets), while more advanced rendering is performed thanks to the 3D library encapsulated in the player module (see section openvibe-vr).

The type manager (see OpenViBE::Kernel::ITypeManager) ensures coherency of all data types. Two kinds of data are manipulated in the platform: simple parameters used to configure boxes, and streams used to connect boxes together and send buffers between boxes. The manager provides a list of registered types, handles conversions and provides information about type compatibility. Simple parameters include integer values, floating point values, strings and filenames. The manager also supports enumerations or bit masks. The stream type tells the scenario editor which box output can be connected to which box input. Stream types are organized hierarchically, allowing to easily downcast some of the streams. For example, an n-electrode raw record will most probably use the signal stream type. This stream type is a specialization of the basic matrix stream type. Thus, each box algorithm working on basic matrix streams will be able to work on raw signal streams.

The plug-in manager (see OpenViBE::Kernel::IPluginManager) makes the platform extensible. This manager is able to dynamically load plug-in modules (e.g., .DLL files under Windows, or .so files under Linux) and collect plug-in object descriptors from them. Then, using these plug-in object descriptors, it provides the service of building new specialized plug-in objects, acting as an object factory for the whole platform. Specialized plug-in objects include scenario serializers, algorithms and box algorithms (see section The plug-ins).

The plug-in system allows to quickly and efficiently expand functionalities. The communication interface between plug-in objects and the platform is defined so that these external objects can be shared, integrated to the platform and replaced when needed.

The plug-ins

Our platform includes three different plug-in families:

The algorithm plug-ins (see OpenViBE::Plugins::IAlgorithm and OpenViBE::Plugins::IAlgorithmDesc) are a generic abstraction for any extension that could be added to the platform (e.g., add a new feature extraction or signal processing methods). Only developers can work with this kind of object. Algorithms are the developer’s atomic objects. The developer may compose several algorithms in order to achieve a complex task. This kind of plugin allows to massively share and reuse software components, even in an offline context where time is managed differently (e.g., EEG file reading or signal visualisation widgets).

The box-algorithm plug-ins (see OpenViBE::Plugins::IBoxAlgorithm and OpenViBE::Plugins::IBoxAlgorithmDesc) are the software components each box relies on. Box algorithms are the author’s atomic objects. The developer describes them in a simple structure that notably contains the box prototype (its name, input/output connectors and settings). The box algorithm itself is responsible for the actual processing, i.e., it reads from inputs, computes data to produce a result and writes to outputs. However, the box algorithm generally combines several algorithm plug-ins together to perform this processing. This ensures fast development thanks to the re-usability of components (e.g., most box algorithms use a specific algorithm in order to easily read from inputs and write to outputs). Thus, the box algorithm can be seen as a set of callbacks called periodically by the player. The most important callbacks are the three notification callbacks (clock tick, input arrival and message arrival) and the actual processing function which produces output data. Each phase of the processing callback can rely on one or more algorithms in order to reuse code.

It should be noted that the box algorithm has a restricted access to kernel functionalities, and can not directly communicate with other box algorithms. A kernel accessor is provided at runtime whenever a callback is triggered, allowing for better flexibility in programming bridges to kernel objects and to other box algorithms.

Currently, the player does not take advantage of computation distribution. However, the box algorithm concept makes such distribution possible and easier because the communication is done thanks to input and output connectors and because box algorithms do not share information directly.

The scenario loading and saving plug-ins allow to keep and reuse created and configured scenarios in files. In addition to loading and saving scenarios, this plug-in can also be used to import scenarios from closely related softwares or to export scenarios to such softwares. The scenario saver basically writes each scenario component into a file. The scenario loader works the opposite way: it reads from a file and creates each box in turn, configuring and connecting boxes together as needed.

With the new build system using CMake for all the heavy lifting it is now possible to use any IDE capable of understanding CMake projects to develop openvibe in integrated manner.

One of the most polished tools for C++ development on linux is the Qt Creator which, contrary to its name, is a general purpose IDE and does not only serve to develop Qt applications.

Setting everything up

The new build system has made it quite easy to use the native building capabilities of any IDE. Still, some tweaks will be necessary to make everything work.

CMake

Openvibe now uses CMake (almost) exclusively to create a build environment. Since Qt Creator has a native support for CMake projects it makes importing very easy.

Run Qt Creator, choose Open File or Project… and in the dialog navigate to the CMakeLists.txt file in the openvibe root.

A dialog will open, prompting you to run the CMake process. To this you will need to provide additional arguments:

 -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=OPENVIBE_ROOT/dist

Do not forget to change the OPENVIBE_ROOT path to location where you put your openvibe files.

Building application

By default, Qt Creator will run make on build and make install before run. This might not be the ideal behavior for openvibe development since the install process can be a bit lengthy. Better way to proceed is to use make install for compiling and skip the compile step entirely before running.

In order to do this go to Projects (on the left) -> Build&Run -> Build. Click on the Details button in build steps and add install as an additional argument to make.

Then go to Tools->Options->Build&Run->General and un-check the Always build before deploying it and Always deploy before running it steps.

Running application

In order to be able to run applications directly from the Qt Creator you will need to set up a few environmental variables for each run setting.

Go to Projects (on the left)->Run. Select the application for which you want to set the run environment. There are several things to change. First you need to change the working path to the /bin folder in the /dist folder made during the install. Change it to:

OPENVIBE_ROOT/dist/bin

Then you will need to set up the environment. The build system makes it so you have a very few of them to set manually. Hint: you can use the batch edit button to edit the variables more easily:

LD_LIBRARY_PATH=OPENVIBE_ROOT/scripts/software/lib:OPENVIBE_ROOT/dist/lib
OV_DISTROOT=OPENVIBE_ROOT/dist

If you are interested in using the Clean Environment instead of the system one, you will also need to set these two up:

DISPLAY=:0
HOME=/home/YOUR_HOME

What you get

Qt Creator has a lot to offer in terms of features.

Semantic code highlighting and full code-completion

As any other respectable IDE, Qt Creator has a parser providing a very good semantic code highlighting and excellent code-completion capabilities. All of this is also very fast.

Subversion integration

The nice thing is that Qt Creator also works with Subversion, albeit the support is quite rudimentary, you can check for modifications of the current file quickly (alt+s, alt+d), commit it instantly (alt+s, alt+c) and a few other handy functions.

Visual debugging

The best improvement is that you can use the visual debugger with all of the features right out of the box without any tinkering.

In order to do this you have, of course, to build the software in Debug mode. In order to do this you will have to re-run the CMake with these arguments:

 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=OPENVIBE_ROOT/dist

Note that it is actually easier on Linux to only ever build the Debug version.

You can also use the Valgrind profiler directly from the IDE.

Hello everyone,

this is a small announcement regarding what is happening in the SVN.

As you can see there were minor tweaks made to the webpage in order to modernize the looks for the new year. Some more changes will be coming later.

In terms of code we have rolled out a new build system for the SVN release. There are some precautions to take so it is best to do a fresh checkout. Note that the code structure did not change, the only differences were made to the CMake files. Also you can still use the branch system for development of separate plugins and of course the openvibe-externals continue working as before.

Currently we are working on simplification of how dependency installation works on Linux and some changes should be rolled out soon.

Be sure to check the newly updated tutorial on software stimulation.

Cheers
The OpenViBE Team

If you wish to use an older openvibe then you should follow these instructions:

If you want to customize the build process, modify the init_env_command script. In case you have trouble using your modified script, the skeletons may represent useful backups. Here are some tips for common developer needs :

• Default behaviour: The script will build all the modules, except the documentation (that you find on the website anyway). After a fresh checkout, please build the software like this once.

• Build a branch instead of module’s trunk: Modify the init_env_command script by specifying the branch path. For example, if you want to try a specific – unstable – driver located in a branch on Windows:

  SET OpenViBE_application_acquisition_server_branch=

  will become :

  SET OpenViBE_application_acquisition_server_branch=branches/wip-unstable-driver

  if you want to try a specific – unstable – driver located in a branch on Linux:

  OpenViBE_application_acquisition_server_branch=

  will become :

  OpenViBE_application_acquisition_server_branch=branches/wip-unstable-driver

• Build only few modules (will work only if all modules have been compiled at least once): Modify the init_env_command script by choosing the project to be added in the build order. For example if you want to rebuild the signal processing plugin on Windows:

  echo %OpenViBE_plugin_signal_processing% >> %OpenViBE_build_order%

  If you want to avoid building the signal processing plugin on Windows, just remove the line or comment it like this:

  REM echo %OpenViBE_plugin_signal_processing% >> %OpenViBE_build_order%

  Similarly, if you want to rebuild the signal processing plugin on Linux:

  $OpenViBE_plugin_signal_processing

  If you want to avoid building the signal processing plugin on Linux, just remove the line or comment it like this:

  #$OpenViBE_plugin_signal_processing

Contributors

Many thanks to our contributors for their continuos support.

• Mensia Technologies (BrainMaster Atlantis and Discovery drivers, BrainProducts ActiCHamp driver)
• Anton Andreev (software tagging capabilities of the Acquisition Server)

OpenViBE is growing

A new research project around OpenViBE has begun. With the ADT openvibeNT project, we have recruited more engineers to work on the software.

In addition, there is a new company called Mensia Technologies that has their core business centered on OpenViBE. The previous OpenViBE creator Yann Renard and the previous OpenViBE lead engineer Laurent Bonnet now work for the company
while continuing OpenViBE-related development.

Release Notes

OpenViBE gets support for more EEG devices

Send stimulations from your application to Acquisition Server

With the External Stimulation feature it is now possible to send stimulations from any c++ application directly to the Acquisition Server which will embed them into the signal acquired from the EEG device. To learn more about this feature please visit the External Stimulation documentation page.

Self-contained scenario configuration

You can now reference files that reside inside the folder of the opened scenario. The $__volatile_ScenarioDir configuration token will always expand to the path of the folder of the current scenario.

Motivation

Some BCI applications require very precise tagging of events. As an example we could look at the P300 paradigm where it is necessary to know the precise moment when the stimulus was presented to the user, in order to find the brain response 300 milliseconds later.

The best way of marking such an event is to detect the stimulus by acquisition hardware and embed the tag inside the signal. However, it is not always possible to do this. Some popular EEG headsets do not have a way to send triggers along with the signal and the majority of current PCs do not possess a parallel port which is usually necessary to send precise hardware stimulations.

In order to address this problem, the Acquisition Server now has the ability to receive stimulations from an external application. These will then be embedded in the signal at the right time.

Implementation

The current implementation uses boost interprocess messages. The advantage of this solution is that it is fast and reliable, the disadvantage is that the external application must run at the same computer as the acquisition server.

Schematically a P300 application using the software tagging would work in the following way:

The description of the bullets follows:

1. The OpenViBE Acquisition Server acquires signal from the EEG device
2. At the same time the External Application sends triggers to the Acquisition Server
3. The Acquisition Server combines signal from the EEG and triggers from your External Application into one stream, triggers are represented as Stimulations
4. The Acquisition Client box will pass the signal to the signal processing chain
5. An optional controller box can give commands (such as target letter) to the External Application via VRPN
6. The processing chain will give commands to the External Application (detected letter)

Example code

Please look at the external_stimulation_connection_example program included in OpenViBE distribution.

Two files are included.

• openvibeStimulationConnection.hpp
  • This header contains the OpenViBE::StimulationConnection class, this class exists to abstract the boost interprocess messaging.
• ovesce_main.cpp
  • This is an example application using the StimulationConnection class. It is a minimal example which, upon execution, sens a OVTK_StimulationId_Beep stimulation to the Acquisition Server.

The StimulationConnection class communicates with the Acquisition Server through a boos interprocess messaging queue. By default the queue’s name is “openvibeExternalStimulations”. Note that if you run several Acquisition Servers on the same machine then, by default, they will all consume the same queue!

The queue’s name the Acquisition Server uses can be changed by modifying the AcquisitionServer_ExternalStimulationsQueueName configuration token.

In order to send stimulations you will have to include the openvibeStimulationConnection.hpp in your source code:

#include "openvibeStimulationConnection.hpp"

The StimulationConnection class is initialized in the constructor:

OpenViBE::StimulationConnection* osc = new OpenViBE::StimulationConnection("openvibeExternalStimulations");

Note that you do not have to specify any parameter to the constructor if you wish to use the default queue name.

Now at any time you want to send a stimulation to the Acquisition Server you can simply call the sendStimulation(uint64 stimulationCode) function. The stimulationCode parameter specifies the stimulation you wish to send (using the standard OpenViBE coding).

osc->sendStimulation(OVTK_StimulationId_Beep);

Copyright Notice: This document was written by Mensia Technologies (2013).

The Brainmaster Discovery and Atlantis driver of the OpenViBE acquisition server is dedicated to Brainmaster devices. These devices have been supported by OpenViBE since version 0.15.0. The driver supports the following models :

• Atlantis 2×2
• Atlantis 4×4
• Discovery 24

Driver properties

Entering the configuration panel of the driver offers a number of options. These options include the common options that you find in all OpenViBE drivers (subject identifier, subject age and subject gender). They also include options related to the specific Brainmaster devices. These options are :

• The COM port to which the device is attached
• The baud rate to use to communicate with the device
• The bit depth of the amplifier
• The notch filter

Note that the sampling rate is fixed to 256Hz.

In order to speed-up the configuration, several “presets” have been included. Choosing a preset will select the best settings for the device you want to use. Available presets are as follows :

• Atlantis 2×2 : turns the configuration to an Atlantis kind of device, 4 channels (2 EEG + 2 AUX), 256 Hz sampling rate, 115200 Bds, 24 bits depth and no notch filter
• Atlantis 4×4 : turns the configuration to an Atlantis kind of device, 8 channels (4 EEG + 4 AUX), 256 Hz sampling rate, 115200 Bds, 24 bits depth and no notch filter
• Discovery 24 : turns the configuration to a Discovery kind of device, 24 channels (22 EEG + 2 AUX), 256 Hz sampling rate, 460.800 Bds, 24 bits depth and no notch filter

Changing any of the device specific settings will turn the preset to “Custom” and let you chose all the settings manually.

Most of the time, choosing appropriate preset will be sufficient for your needs.

Configuration panel for Atlantis kind of devices

Atlantis 2×2

Atlantis 4×4

Configuration panel for Discovery kind of devices or manually configured devices

Discovery 24

Manually configured device

Choosing the COM port

The COM port can be autodected. In order to do that, the Brainmaster Discovery and Atlantis driver tries each COM port from COM 1 to COM 16 until it finds one that can be opened. It happens that some ports can be opened even if no Brainmaster device is plugged to them (for instance modem and bluetooth devices usually use COM ports as well). If the detection went wrong, feel free to set the COM port manually and according to the Windows Device Manager.

Device Serial Nr and Device Passkey

These fields must be set in order to use Brainmaster devices with OpenViBE.

The device serial number can be found on a sticker on the back of your device. Its format is as follows : XXXXX (where X are numbers)

The device passkey should be requested to Brainmaster support. It is a different key than the one you have for Brainmaster software. Its format is as follows : XXXX-XXXX-XXXX (where X are numbers or letters).

In order not to set-up the keys each time you start the acquisition server, you can set the following environment variables to your OpenViBE configuration file :

AcquisitionServer_Driver_BrainmasterDeviceSerial
AcquisitionServer_Driver_BrainmasterDevicePasskey

Here is an example of openvibe.conf that would include these tokens :

AcquisitionServer_Driver_BrainmasterDeviceSerial = 12345
AcquisitionServer_Driver_BrainmasterDevicePasskey = 1234-abcd-wxyz

Troubleshooting and frequently asked questions

My device has 5 (resp. 10) EEG electrodes but the channel name changing panel shows only 4 (resp 8) channels.

Atlantis devices use two electrodes per EEG channel. This means each EEG channel has a possibly independent reference. This is different of what is commonly used in BCI or more generally in higher number of electrodes setups. Atlantis 2×2 uses the following 5 electrodes : A1, R1, G, A2, R2. This results in two channels, first one is the difference of potential from A1 to R1 (namely A1-R1), second one is the difference of potential from A2 to R2 (namely A2-R2). The other two channels are the 2 Auxiliary channels. Atlantis 4×4 is designed in the same way : 10 electrodes A1, R1, G, A2, R2, A3, R3, G, A4, R4. This results in four channels : A1-R1, A2-R2, A3-R3, and A4-R4. The other four channels are the 4 Auxiliary channels. As regarding to the ground electrode, as for any OpenViBE driver, it is never considered in the Acquisition Server.

I am not using Auxiliary channels but the driver won’t let me disable their acquisition

Just use a Channel Selector box after the Acquisition Client box to keep the channels you are interested in and leave the others out.

The COM port can is not detected correctly

Go to the Windows Device Manager (Right click on My Computer, followed by Manage, followed by Device Manager)
Find your Brainmaster device and click Properties
Find the COM port your device is connected to
Use this COM port in the acquisition server configuration panel

The acquisition server says “Could not log in device”

Check that your serial number is set correctly
Check that your passkey is set correctly
Check that you use the passkey you received from Brainmaster for OpenViBE and that you are not using the passkey that should be used for Brainmaster
Try with a lower Bds rate

Atlantis and Discovery presets deactivate notch filter, is it normal ?

Yes it is normal. OpenViBE users usually want the signals as “raw” as possible. The notch filter can be done in software using the “Temporal Filter” box if needed. Still hardware filter usually have better performances than software filters. So for that reason and as an option, you can change these settings manually and go ahead with a pre-filtered signal.

I still have problems using my Brainmaster device with OpenViBE

Edit your OpenViBE configuration file and set the log level to Trace

Kernel_MainLogLevel = Trace

Then run several tests with the acquisition server and save the openvibe-acquisition-server.log file in a safe place. Finally go to the OpenViBE forum (http://openvibe.inria.fr/forum), precisely describe the problem you are facing and attach the log file accordingly.

I know Brainmaster devices and want to be sure what is acquired from the device (raw datastream)

The raw content of the data stream can be dumped in a text file. In order to activate this feature, edit your configuration file and point the appropriate variable to the file you want to dump the stream in.

AcquisitionServer_Driver_BrainmasterFrameDumpFilename = c:/dump.txt

Then run the acquisition server. Note that each use of the acquisition server will overwrite the previous dump.

It happens that the acquired signal looks choppy

OpenViBE implements a drift correction process to allow devices without hardware triggers to reliably tag signals during acquisition. The “reference” clock for this process is the computer’s clock. As their is no hardware sync between the device and the computer’s clock, it happens and it is normal that some devices drift (that is : instead of sending the promised 256 samples per second, they send 256.1 samples per second for instance). As the computer clock is the clock OpenViBE considers as a reference, it has to add and/or remove a fraction of the acquired samples accordingly. While acquiring and inspecting signals with a “Signal Display” box, one should see vertical dashed line for each correction due to drift. This can be checked doing the following actions :

1. in the designer connect the “stimulations” output of the acquisition client to the “stimulations” input of the signal display
2. run the scenario
3. you should see a vertical dashed line for each correction due to drift

This issue can be solved reducing the buffer size and latency of the COM port which the device is connected on. Indeed the default settings cause the OS to buffer the data in big blocks. During the buffering period, OpenViBE believes the device does not send enough samples and adjusts the drift accordingly. As soon as a -big- block of samples gets to OpenViBE, it realizes too many samples were acquired (as it adjusted the drift previously) so it -again- adjusts the drift in the opposite way, causing the signal to be significantly modified (this is the worst scenario happening for the drift correction process !).
In order to reduce the buffer size and latency of the COM port, process as follows :

1. Right click on the “My computer” icon
2. Go to “Manage”
3. Go to the “Device Manager”
4. Go to “COM and LPT ports”
5. Go to your Discovery COM port
6. Go to “Port parameters” tab
7. Change baud rate to 460800 (Discovery) or 115200 (Atlantis)
8. Go to “Advanced”
9. Set the reception / transmission buffer size to at most 64
10. Set the latency to at most 2ms
11. Set the delay for reading and writing to 0

The drift correction process does not matter to me, how can I disable it ?

It is not recommended to disable the drift correction process. However, if you still want to disable it, process as follows :

1. in the acquisition server, go to “Preferences”
2. in the “drift correction” combo box, select “disable”
3. start the acquisition server
4. at some point you’ll probably see the drift gauge moving out of its allowed boundaries – but this will keep all the acquired samples

Copyright Notice: This document was written by Mensia Technologies (2013).

Introduction

This document describes how to use the OpenViBE driver for a BrainProducts actiCHamp amplifier. The documentation will cover the device capabilities, the corresponding driver and server configuration, and answers to frequently asked questions. This driver is available in OpenViBE version 0.15.0 and newer.

Presentation of the device

The actiCHamp amplifier has the following characteristics and possibilities:

• 32 to 160 channels, using up to 5 expansion cards of 32 channels
• To be used with actiCAP active electrode sets
• 8 auxiliary channels
• 8bit trigger output and input
• 10kHz, 50kHz or 100kHz physical sampling frequency
• Impedance mode to check electrode contacts
• BrainProducts Active Shield for noise reduction
• Internal ADC data filter (Averaging x2)
• Internal ADC data decimation (factor 2)
• USB connection

Figure 1: BrainProducts actiCHamp

Driver configuration

The OpenViBE driver for the BrainProducts actiCHamp device can be configured to access most of the amplifier capabilities. Here is a snapshot of the driver configuration panel :

Figure 2: driver configuration

Experiment information

First is the experiment information, common to any OpenViBE driver, that we be send through the OpenViBE data stream for the records :

Figure 3: Experiment information

Acquisition configuration

Second part is the actiChamp acquisition configuration:

Figure 4: acquisition configuration

User can select the device. The index depends on the USB index in which the amplifier is plugged.

The number of channels is disabled, as this number is deduced from the number of modules currently activated, set in the last part.

The sampling frequency of the data stream produced by the driver can be chosen from the following list : 128Hz, 256Hz, 512Hz, 1024Hz, 2048Hz, 4096Hz. Note that these sampling frequencies dos not correspond to the physical sampling frequency of the EEG amplifier, and are the most common sampling frequencies used with OpenViBE.

The physical sampling rate of the amplifier is set to 10kHz and cannot be modified.

Whereas the device can handle 100, 50 or 10kHz (plus 25 and 5kHz using the built-in decimation), usual BCI applications and OpenViBE in particular are not handling such high sampling frequencies. Most of the EEG components studied are < 100 Hz, thus a sampling frequency of 512Hz is common for practical research with OpenViBE. The scenarios given with OpenViBE suppose a 512Hz sampling frequency.

We apply a well-adjusted software decimation, with software low-pass FIR filter before downsampling. This process induces a 50ms fixed delay, which is compensated by the Acquisition Server automatically (acquired samples are time-stamped accurately).

The acquisition mode may be set to:

• Normal, for basic acquisition
• Active Shield, for acquisition with this noise-filtering algorithm (recommended)
• Impedance, to check continuously the electrode impedances
• Test, to send a square signal continuously on every channel

The ADC data filter can be set to either Native (no ADC data filter) or Averaging x2 samples.

User can also activate the data decimation (factor 2).

The Active Shield gain can be set manually (in percent). Default value (5) is recommended.

Finally, the impedance limits of the actiCap can be manually set. Below the Good impedance limit, electrodes LEDs will be green. Above the Bad impedance limit, the LEDs will be red. Between these two bounds the LEDs will be yellow.

Channel management

The last part is the channel selection and naming.

Figure 5: channel management

The actiCHamp driver detects automatically the number of extension cards connected to the amplifier. For example on this screenshot 2 modules are detected.
User can select the modules to activate by toggling the corresponding buttons.

The 8 AUX channels can be activated by checking the corresponding box.

Finally, channel names can be set as with most of the OpenViBE drivers. If you are using the BrainProducts easycap 64 channels EEG cap, you can use the electrode placement list provided with the driver. This file can be found in (share/openvibe-application/acquisition-server/easycap- 64ch-electrode-names–10–20.txt).
Alternatively, a Channel Rename box can be used within an OpenViBE scenario. A box configuration file is also provided (ov-channel-rename-easycap–64ch.cfg in the same folder).

Acquisition Server configuration

As with every OpenViBE driver, the Acquisition Server automatically detects drift and jitter in the “real” sampling rate of the device compared to the theoretical rate.

When using the actiCHamp amplifier, user should consider adjusting the drift correction parameters to lower the number of unnecessary corrections (e.g. adding samples that will be removed shortly after) , as recommended in the configuration panel header:

Figure 6: recommendations

With default acquisition settings, adjusting the jitter estimation count to 500 in the Acquisition
Server preferences is recommended.

Triggers and My Button

The actiCHamp driver for OpenViBE is managing the input triggers that the device may receive through parallel port, and the My Button in front of the amplifier that can be pressed at will to notify some events.

The device has 8 input trigger bits, the input trigger line can thus be seen as a number between 0 and 256. The trigger states are translated into one OpenViBE stimulation code, in the range OVTK_StimulationId_LabelStart (33024 – all triggers to 0) to OVTK_StimulationId_LabelEnd (33279 – all trigger to 1).

For example, receiving the stimulation code 33068 means that the trigger line has the value 33068 – 33024 = 44.

44=2⁵+2³+2²

The code 33068 tells you that the input trigger at index 5, 3 and 2 are activated. Triggers at indexes 0, 1, 4, 6 and 7 are off.

The OpenViBE acquisition server will send a new stimulation every time the driver detects a change in the input trigger line. The MyButton state is also translated into OpenViBE stimulation codes:

• MyButton is pressed, server sends the stimulation
  OVTK_StimulationId_Button1_Pressed (32786)
• MyButton is pressed, server sends the stimulation
  OVTK_StimulationId_Button1_Released (32787)