Specific software implementations for realtime EEG/MEG/fMRI/NIRS

This page is part of the documentation series of the Fieldtrip buffer for realtime aquisition. The FieldTrip buffer is a standard that defines a central hub (the FieldTrip buffer) that facilitates realtime exchange of neurophysiological data. The documentation is organized in five main sections, being:

  1. description and general overview of the buffer,
  2. definition of the buffer protocol,
  3. specific implementations that interface with acquisition software, or software platforms.
  4. the getting started takes you through the first steps of real-time data streaming and analysis.

This page deals with specific implemenations of the FieldTrip buffer protocol. This includes interfacing with specific hardware (e.g. TMSi, Biosemi, CTF), software platforms (e.g. BCI2000, BrainStream) and links to the implementation in specific programming languages (e.g. MATLAB, Java, C/C++, Python).

  • Java client-side implementation
  • Python client-side implementation
  • Arduino client-side implementation
  • BCI2000 includes the FieldTripBuffer and the FieldTripBufferSource modules
  • BrainVision RDA interface allows streaming data in the RDA format
  • BrainStream is directly supported through shared MATLAB code

Recording and playing back online experiments

There are two applications, based on the FieldTrip buffer, that allow to record an online experiment for later playback at the original “speed”, and thus help developers with debugging and testing different analysis schemes. WARNING: The file format used is not 100% finalised yet, so we advise against using these tools for archiving your data.

The first application, recording, will act to the outside world as a normal FieldTrip buffer server. Internally, however, every incoming request is also handed to a callback function that stores all incoming data on disk. The program resides in fieldtrip/realtime/acquisition/general/ and is called like this:

recording someDirectory [port=1972]

This will spawn the callback-enabled buffer server on the given port, create the given directory (which must NOT exist already), and write a plain text file contents.txt into that directory. This file is always the same and just contains a general description of the way the recording writes data. Now, each time a header is written, a new subdirectory (starting with 0001) is created, the header is written there in binary and ASCII form, and all further samples and events are also written to binary files. The arrival time of incoming sample and event blocks is measured relative to the arrival time of the header, and logged in an ASCII file called timing. For stopping the operation, the user may safely press CTRL-C which will close down the server thread and close any open files.

The other application, playback in the fieldtrip/realtime/acquisition/general/ directory, can be started like this

playback someDirectory/0001 hostname port

This will replay the data recorded in the first “session” above, at almost exactly the original timing. In contrast to recording, this application will not spawn its own buffer server, but it can only stream data to a remote server. The design rational for this was that you might want to replay an experiment several times, but keep the buffer server running in a similar way as it's done with real acquisition systems.

To create a new buffer you can call this from matlab using ft_create_buffer

Language Client Server Notes
C yes yes Reference implementation, please see here
C++ yes yes Thin wrapper classes around the reference implementation for handling client requests, please see here
Matlab yes yes Full support via MEX files, please see here
Python yes no this depends on Numpy, please see here
Java yes no please see here

For a real-time BCI system, it is important that a control signal somehow can be used to close the loop towards the subject. Here you can find a description on the options that you have for closing the loop from within your Matlab-based BCI application.

Current plans and design considerations for building a general pipeline architecture can be found here.