Interface with MATLAB and FieldTrip

The difference between the two interfaces to MATLAB is that the MatlabFilter causes some pre-specified MATLAB code to be executed in the BCI2000 pipeline, i.e. BCI2000 stays in control over the timing and the MATLAB session only sees a small fragment of the data. That also forces you to write your MATLAB code to use recursive/incremental updating schemes.

The FieldTripBuffer interface to MATLAB allows you to control the timing from within MATLAB and read arbitrary sections of data from the ongoing data stream as if it were a continuously growing file, giving more flexibility in the MATLAB code that you can employ. The advantage of the FieldTripBuffer interface is that you have all control in MATLAB that you are used to. You can write your MATLAB code for offline-analysis (i.e. reading data from a file) and apply exactly the same code to online analysis (i.e. reading from BCI2000). Of course for the online analysis to make some sense, your analysis script has to be meaningful and has to work with relatively small data fragments (e.g. one second or less), otherwise the MATLAB code would not really run in real-time. Another interesting feature is that in MATLAB you can use the profiler (type “help profile”) to determine which parts of your code take a long time to execute and speed those parts up.

On this page you can find example code that demonstrates how to interface FieldTrip and BCI2000.

On this page you can find background information from the BCI2000 perspective.

The MatlabFilter and the FieldTripBuffer interface to MATLAB are supported for any acquisition system that is supported by BCI2000 in general. For an overview of
such systems, please see these pages on devices supported in core BCI2000 and further tools for data acquisition contributed to BCI2000.

FieldTrip buffer source module

We have developed FieldTripBufferSource, a BCI2000 signal source module that reads data and events from a FieldTrip buffer, and thus behaves like an acquistion system from BCI2000's point of view. The user needs to configure the hostname and port where the buffer resides, the blocksize, the number of channels, and optionally a list of states that will be modified according to the value of equally named events from the FieldTrip buffer.

Note: Similarly to the aforementioned FieldTripBuffer filter, the FieldTripBufferSource module does not define any state variables on its own.
This means that it's not possible to translate general buffer events to BCI2000 states, but only events whose type string matches the name of
an exisiting state variable in BCI2000 (e.g., 'Recording'). As a possible future extension, it would be nice to flexibly adapt the source module
to the type of events that are being written to the buffer for a particular application.