Driver for ModularEEG / OpenEEG

[Chris Veigl]

Hello all,

I currently try to write a driver for the OpenVibe acquisition server to work with the OpenEEG amplifiers
(http://openeeg.sourceforge.net/)

Respectively, the original P2 Packet format of ModularEEG and MonolithEEG will be supported at first.

I started with the OpenVibe Source Distribution for Linux and built the software on a recent Ubuntu 9.04 OS.
(I ran into some issues which could be reported in an extra thread ..)

Using the OpenVibe documentation and the tutorial slides, driver coding was pretty much straight-forward.
I can now see the 14Hz-calibration signal and the 6-Channels of a running ModularEEG unit in the signal display of OpenVibe designer

Current development questions:

-) how to deal with platform-specific code ? - it did not seem to me that the OIS-library supports e.g. Serial Port handling ...
I decided to use native linux calls to open / configure / read from the port (which is curently an FTDI-generated /dev/ttyUSB0 device in my setup)
I used #ifndef OVAS_OS_Windows etc. to compile the platform specific code.
however, it should be no problem to add the windows-specific calls to have linux and windows build working, but i do not know how to do this on the MAC ...

Some user questions:

-) I do not get output from the "Graz visualisation" plugin for mu-BCIs (neither on linux nor windows) - are there prerequisites ?
-) Is it possible to use the VR-scenarios, maybe with a freeware VR-Renderer ?


thank you very much for your great work !
best regards,
Chris.

[yrenard]

(I ran into some issues which could be reported in an extra thread ..)

Already answered several things in the other thread...
For readers, check the Developing acquisition interface thread.

-) how to deal with platform-specific code ? - it did not seem to me that the OIS-library supports e.g. Serial Port handling ...
I decided to use native linux calls to open / configure / read from the port (which is curently an FTDI-generated /dev/ttyUSB0 device in my setup)
I used #ifndef OVAS_OS_Windows etc. to compile the platform specific code.
however, it should be no problem to add the windows-specific calls to have linux and windows build working, but i do not know how to do this on the MAC ...

Using OVAS_OS_* macros is a pretty nice way to do it. My preference would be to write an openvibe-module (as in openvibe-module directory in the gforge) that would do those platform testings within a portable abstraction. Your driver would actually use this specific portable module to do what it has to do. Consequences are that other driver developers would be able to take advantage of this serial port communication module, and you would benefit of its enhancement by other driver developers. But anyway, for a first shot, using OVAS_OS_* macros it OK !

-) I do not get output from the "Graz visualisation" plugin for mu-BCIs (neither on linux nor windows) - are there prerequisites ?

You can find a working scenario in the share/openvibe-scenarios/bci folder. It should work, tell me if it does not. (The recorded files included 40 seconds of baseline so you have to fast forward to 40 seconds in order to see something )

-) Is it possible to use the VR-scenarios, maybe with a freeware VR-Renderer ?

I don't really understand what you want here.

thank you very much for your great work !

Thank you for your interest and thank you for your contribution. I hope you'll keep working on & for OpenViBE

Yann

[Chris Veigl]

My preference would be to write an openvibe-module (as in openvibe-module directory in the gforge) that would do those platform testings within a portable abstraction. Your driver would actually use this specific portable module to do what it has to do. Consequences are that other driver developers would be able to take advantage of this serial port communication module, and you would benefit of its enhancement by other driver developers. But anyway, for a first shot, using OVAS_OS_* macros it OK !

all right.

-) I do not get output from the "Graz visualisation" plugin for mu-BCIs (neither on linux nor windows) - are there prerequisites ?

(The recorded files included 40 seconds of baseline so you have to fast forward to 40 seconds in order to see something )

OK - didn't know that ..

-) Is it possible to use the VR-scenarios, maybe with a freeware VR-Renderer ?

I don't really understand what you want here.

i'd like to run the 3d scenarios (football/starfighter) from the video tutorials,
but i assume i have to install a seperate VR - Rendering client which talks to the VRPN server.
i'm not sure if i should download/use OpenMask or what is needed to get the setup running.


thanks,
chris

[yrenard]

OpenMASK should be installed/compiled with OpenViBE dependencies.

If you want to compile / use VR applications, edit your init-env-command script and uncomment all the OpenViBE_application_vr_demo related lines. You will have those tie-fighter / handball applications ready to run !

Yann

[mswynghedauw]

hi all
what is the current state for the modularEEG driver of openvibe?
any Win32 version ?

are the src accessible somewhere ?

thx
m

[yrenard]

Hello mswynghedauw and welcome on this board,

the modular EEG driver is not yet included in the official release of OpenViBE. There are a couple of details to tweak before definitve inclusion... But you can find the driver and include it in the acquisition server yourself based on this post

Yann

[ChangeWind]

Open-ViBE: a 3D Platform for Real-Time Neuroscience
Hi Yrenard,
Is the connection to Loreta as described is already in the existing OpenVIBE package?

[ChangeWind]

Hi Yrenard, is there a topic or links or a page sumamrizing the effort in the direction of real-time acquisition and source localization using Loreta and openvibe? Thank you

[yrenard]

Dear ChangeWind,

the voxel visualisation as shown on this picture is included in the existing package. It uses an inverse model to reconstruct the sources. In the demonstration scenario, you will find that the Voxel Display box is unstable. This is because we had difficulties making it run realtime whatever voxel is displayed. You will have to play with the parameters to choose what voxels to show in order to make it run realtime.

About the acquistion, I'm not sure to understand what you mean, it runs realtime without a problem... OpenViBE can be used for BCI, right ?

Yann

[ChangeWind]

Hi Yrenard, thanks for prompt reply. Appreciate.

Can you give a sample of the
win32-init_env_command.cmd

[yrenard]

Dear ChangeWind,

you have on in the script folder called win32-init_env_command.cmd-skeleton. You won't have to change this file until you want to use someone's branch better than the trunk.

Yann

[ChangeWind]

Thanks very for your help through IRC, successfully compiled.
Everything is automatic.
For compiling in VISTA
a) Download through SVN
b) run Dependency install
c) rename the provided env-skeleton to win32-init-env.cmd and run it
d) run win32-build.cmd and then go for coffee
e) if you need visual express++, after the coffee, run win32-generate-vc-proj
f) send a thanks note to the team

[yrenard]

Thank you for your feedbacks ! We need them !

Yann

[mswynghedauw]

Hi all
i have a little trouble.

when i use the stimulation based epoching. i fill the proper stimulation to epoch from , but when the signal is displayed into a signal diplay, the
result is weird.
the epoch is duplicate many times into the display, so i dont understand anything of whats going on.
in fact, on a more general aspect, it'll be nice to be able to surimpose all the epoch onto the same display (not following each other). average the signal, etc... well be able to preview any basic statistical anaylsis.

also i tried the driver for the modularEEG in the v4 and it does not work. i rewrote another one that work (for me...) based on the src available from brainbay.

last thing i develop a soundplayer module. using SDL lib. that can play wav file, loop them, and play randomly another file (for auditory P300 for ex.), if anyody is interested.

m

[yrenard]

Hello mswynghedauw,

The signal display's purpose is to display continuous signals. It never displays less than one epoch so you can use it to display a single ERP at a time simply putting a time scale as small as possible. If you want an averaging of this ERP, just put an epoch average box before the signal display. You can't overlay successive ERP with signal display for now.

Concerning your feedbacks, first, I want to thank you very much, we need those feedbacks.

For the ModularEEG driver, have you filled a bug report explaining what the problem was ? We don't have such hardware ourselves to test. Have you tried to contact Chris Veigl ? He developed this hardware and most likely will answer your questions if needed. Maybe we can discuss all three of them about a correction / mix of your own implementation from Brainbay ?

Concerning the sound stuff with SDL, feel free to submit your contributions !

Best regards,
Yann