Category Archives: Research

EEG combined with VR

16 Replies

We recently had a meeting at the Astron radio telescope for the COGITO project with Daniela de Paulis, Stephen Whitmarsh, Guillaume Dumas and others. One of the goals of that meeting was to try out the combination of the EEG system with the Oculus Rift VR system.

For the COGITO project we are using the GTec Nautilus EEG system. Our specific system comprises of a 32-channel wireless amplifier that mounts on the back of the EEG cap, in combination with EEG caps in three different sizes. The caps have 64 holes at a subset of the  locations of the 5% electrode placement standard. We are not using the “Sahara” dry electrode option, but rather the regular wet electrodes.

We started by removing all electrodes and cups from the cap, to get a clear view on which electrode sites are accessible. The central electrode locations (i.e. the z-line), temporal electrode locations and occipital electrode locations are occluded by the VR head mount. But there are still plenty of electrode locations accessible.

Continue reading →

The Nike EEG headband

1 Reply

Together with Stephen Whitmarsh and friends I have embarked on the EEGSynth project, which aims to bridge science, technology and art by making an EEG-based synthesizer. The EEGSynth project relies on the realtime functionality in our FieldTrip toolbox, although it will probably also be linked to other software platforms.

I am lucky to have one of the first Jinga-Hi JAGA16 wireless EEG systems, which I think is the the smallest and most portable EEG system in existence at the moment. Although the primary application of that system is not for human EEG, it actually is perfectly suited for wireless BCI and neurofeedback applications as well. I am combining this system with standard (clinical and research) EEG cup electrodes. Using a glob of Ten20 electrode paste you can stick them to the scalp. Having some of these electrodes on my head and trying to connect this bunch of long wires to the tiny JAGA16 wireless EEG amplifier resulted in the question how to make a comfortable and robust system for electrode attachment.

I came up with the idea to use an elastic sports headband. This allows to attach the wireless amplifier to the head, and consequently the electrode wires would be channeled along the headband. Here you can see the components that I started with (minus the EEG amplifier):

2015-05-19 21.09.54

The headband is one that I picked up in a local sports shop. It consists of a sleeve of flexible fabric that  is relatively thin. At the placed where the fabric needed puncturing, I used some iron-on interfacing to strengthen it and prevent the holes from further tearing.

2015-05-19 21.51.46

This is the end result, which includes 8 electrodes for the EEG and 2 for the ground and reference.

2015-05-19 23.53.52

Soldering the electrode leads to the miniature connector was the hardest task. The 18 pin (arranged as 9×2) connector is only 12 mm wide, which means that for each pin there is only about 1.2 mm space.

Note that the PCB board with the yellow wrapping is actually  the full 16 channel wireless amplifier. It is powered by a (cell-phone type) LiPo battery, which is as large as the EEG system. Data is transmitted over Wifi and can be streamed and analysed in MATLAB or Python using  FieldTrip.

2015-05-19 23.54.20

Here I am, wearing the first prototype electrode headband. Two electrodes (ground and reference) go behind the ears, the other eight electrodes are approximately placed at F3, F4, C3, C4, P3, P4, FCz and CPz. The wifi EEG amplifier and the battery can conveniently be tucked away in the two flaps at the back.

2015-05-20 16.16.22

First steps to realtime EEG and BCI on Raspberry Pi

2 Replies

I just compiled the FieldTrip realtime EEG interface on the Raspberry Pi. The code compiled out of the box, not a single line of code needed to be changed thanks to the existing cross-platform support for the old Apple PPC-G4 and the Neuromag HPUX-RISC MEG system. Streaming data to and from the FieldTrip buffer over TCP/IP works like a charm.

I’ll add my binaries for the Raspberry Pi to the regular FieldTrip release.

The next step will be to compile some of the EEG acquisition drivers, e.g. for OpenEEG and BrainVision.

Eventually it would be nice to also get BCI2000 to work on the Pi. According to Juergen large parts of BCI2000v3 should compile on the ARM… I look forward to gving it a try.

Torque batch queue system for mentat

Leave a reply

I have installed the torque batch queue system on our 50 node (~300 core) mentat cluster. Here are some useful PBS commands that can be used with Torque.

qsub script
Submit a job script for execution.
qstat
Show status of running and pending jobs.
tracejob
Display historical information about your jobs.
qdel
Kill a job.
qhold
Hold a job.
qstat -Q
qstat -Qf
Show configuration of queues.

Peer-to-peer distributed Matlab computing – update

2 Replies

After discussing in detail with colleagues at the Donders and at the FIL, I have implemented the peer-to-peer distributed computing toolbox for MATLAB. Most of the desired functionality is now in place, and it seems to work robustly and efficiently.

The peer toolbox allows you to do something like this in MATLAB

a = randn(400,400);
tic; cellfun('pinv', {a, a, a, a, a}, 'UniformOutput', false); toc
tic; peercellfun('pinv', {a, a, a, a, a}, 'UniformOutput', false); toc

Continue reading →

Peer-to-peer distributed Matlab computing

Leave a reply

In a recent meeting with the SPM developers, we discussed parallel computing using the Matlab distributed computing toolbox, Star-P, Sun Grid Engine, and other batch systems that can be linked to Matlab. These are all limited in their usefulness for the typical neuroimaging research setting in that they are based on a centralized job distribution system. That may work fine on a large cluster with a centralized configuration and system administration, but even then the usefullness is limited because all input and output data (which are typically large) have to be send over the network twice: first to the job manager, then to the compute node (and vice versa for the results).

To resolve some of these problems, I came up with the idea of peer-to-peer distributed computing in Matlab. The full description can be found on http://fieldtrip.fcdonders.nl/development/peer

Automatically compile a missing mex file on the fly

Leave a reply

I am maintaining a few open source Matlab toolboxes. Although most functions are plain Matlab, some functions are implemented as mex file. The mex files have to be compiled on each platform, i.e. 32 and 64 Linux, 32 and 64 bit Windows, ppc and intel Mac OS X, etc. Since I don’t have access to all those platforms, I have devised a trick to automatically compile the mex files on the end-user’s platform.

Let’s say that you have a function mymexfile, then the file mymexfile.c would contain the c-code implementation of the Matlab mex file. You should save the following code as mymexfile.m. If the compiled mex file (e.g. mymexfile.mexw32) does not exist upon the first call to the function, the m-file will be executed. The m-file will automatically compile the c-file and will subsequently call the compiled mex file. On all subsequent calls, the compiled mex file will be executed directly.

function [varargout] = autocompile(varargin)

% AUTOCOMPILE compile the missing mex file on the fly

% remember the original working directory
pwdir = pwd;

% determine the name and full path of this function
funname = mfilename('fullpath');
mexsrc = [funname '.c'];
[mexdir, mexname] = fileparts(funname);

try
% try to compile the mex file on the fly
warning('trying to compile MEX file from %s', mexsrc);
cd(mexdir);
mex(mexsrc);
cd(pwdir);
success = true;

catch
% compilation failed
disp(lasterr);
error('could not locate MEX file for %s', mexname);
cd(pwdir);
success = false;
end

if success
% execute the mex file that was juist created
funname = mfilename;
funhandle = str2func(funname);
[varargout{1:nargout}] = funhandle(varargin{:});
end