BCI2000 Glossary: Difference between revisions
Wengelhardt (talk | contribs) No edit summary |
Wengelhardt (talk | contribs) No edit summary |
||
| Line 12: | Line 12: | ||
==Modules== | ==Modules== | ||
BCI2000 ''always'' runs 4 executables, called modules. The first is ''always'' the Operator module. The other 3 ''must be'' one each of a Signal Source module, a Signal Processing module, and an Application module. | BCI2000 ''always'' runs 4 executables, called modules. The first is ''always'' the Operator module. The other 3 ''must be'' one each of a Signal Source module, a Signal Processing module, and an Application module. | ||
[[File:Modules.png|center|500px]] | |||
#'''Signal Source''': The module that acquires the data. This connects to the hardware, buffers the data, saves it to the data file and sends it to the signal processing module. | #'''Signal Source''': The module that acquires the data. This connects to the hardware, buffers the data, saves it to the data file and sends it to the signal processing module. | ||
#'''Signal Processing''': Conducts any signal processing on the raw data and transmits it to the application module. | #'''Signal Processing''': Conducts any signal processing on the raw data and transmits it to the application module. | ||
#'''Application''': Runs any task and provides any output to the user, such as stimulation. | #'''Application''': Runs any task and provides any output to the user, such as stimulation. | ||
#'''Operator''': Provides user interaction and communication between modules. Since this never needs to be changed, new users don't need to worry about this. | #'''Operator''': Provides user interaction and communication between modules. Since this never needs to be changed, new users don't need to worry about this. | ||
This design maximizes modularity. Any module can be swapped out (e.g., changing the task, changing the amplifier) and the rest of the pipeline will stay the same. | This design maximizes modularity. Any module can be swapped out (e.g., changing the task, changing the amplifier) and the rest of the pipeline will stay the same. | ||
Revision as of 18:44, 16 April 2025
A glossary of terms specific to BCI2000.
Data Types
All of BCI2000 data is contained in one of 3 types: parameters, signals, or states.

- Parameters: Configuration settings. These are set at the beginning of an experiment, and constant throughout the run. In analysis, they can be used to completely replicate the set-up of the experiment.
- Signal: The main data stream, usually the neurophysiological data from the amplifier.
- States: Secondary data streams. These should be any data that changes throughout the run. This includes behavioral data (mouse, keyboard, task responses), task behavior (stimuli, other task data), and physiological data (eye-tracking, motion tracking). These are aligned to the main data stream (signal) in the data file.
BCI2000 data is stored in a .dat file, which contains only parameters, states, and signals.
Modules
BCI2000 always runs 4 executables, called modules. The first is always the Operator module. The other 3 must be one each of a Signal Source module, a Signal Processing module, and an Application module.

- Signal Source: The module that acquires the data. This connects to the hardware, buffers the data, saves it to the data file and sends it to the signal processing module.
- Signal Processing: Conducts any signal processing on the raw data and transmits it to the application module.
- Application: Runs any task and provides any output to the user, such as stimulation.
- Operator: Provides user interaction and communication between modules. Since this never needs to be changed, new users don't need to worry about this.
This design maximizes modularity. Any module can be swapped out (e.g., changing the task, changing the amplifier) and the rest of the pipeline will stay the same.
Control Signal
The output of the signal processing module. When the Normalizer Filter is used, this signal has zero mean and unit variance.
Core Module
One of Data Acquisition, Signal Processing, and User Application Module. These are called core modules because they are involved in on-line processing, as opposed to the Operator Module, which controls operation, and passively displays data sent by core modules, but is not actively involved in processing.
Filter
A software component that is part of the BCI2000 processing pipe, or filter chain. Once per sample block, filters are called to act on data in a sequential fashion. A filter maintains its own parameters, and enables the user to configure its behavior from the operator module.
Module
A single executable that may act as Operator Module or one of the Core Modules.
Operator Module
The experimenter's user interface, from which the system is configured, started, and stopped.
Parameter
A system-wide setting that is constant during a run. Parameters may be of varying type (numeric, string, etc.) and shape (single-valued, list, matrix).
Roundtrip
The time needed for a sample block to traverse the core modules. To fulfil the real-time constraint, roundtrip time may not exceed the physical duration of a sample block.
Run
The time period corresponding to a single data file. A run comprises a number of trials. From the user's view, a run starts when the operator's Start button is clicked, and ends when operation is suspended, either by the application module, or by a click on the Suspend button.
Sample Block
BCI2000 processes data in chunks, which are called Sample Blocks, or Data Blocks. Sample block size is configured through the SampleBlockSize parameter; often, ADC hardware imposes restrictions on sample block size.
The physical duration of a sample block is the inverse of the screen update rate, and determined by the ratio of sampling rate to sample block size.
Session
A number of runs of the same participant, recorded in sequence. Files from a session are recorded into a single data directory.
Source Signal
The signal that is acquired from hardware by the ADC filter, and recorded into the data file. The TransmissionFilter reduces the source signal to a user-defined subset of channels to reduce processing load in the on-line system.
State
A system-wide variable similar to what in other data acquisition applications is often called "event marker." State variables reflect important events during real-time system operation, and are saved to the data file along with each sample. Depending on how states are used, they come in three flavors:
- Plain state variables may be used to annotate information to signal data, e.g. by the SignalProcessing module,
- Stream state variables are used by source modules to store additional information synchronously with the input signal, e.g. the state of digital inputs,
- Event state variables are used to asynchronously log event marker information, e.g. a keypress, or presentation of a stimulus.
State Vector
A data structure that contains all states concatenated into a single bit string. The state vector is transmitted between modules once for each sample block, but a copy is saved with each sample of data.
Task
In a wider sense, the subject's task in a feedback experiment. In BCI2000, a piece of software that implements feedback (or, more generally, stimulus presentation) to the subject. In a BCI2000 application module, the task-defining software element is termed a "task filter".
Trial
In a cursor feedback paradigm, the time period during which the user moves the cursor. In an ERP paradigm, the time period following a single stimulus presentation.
Visualization
A core module may send information into a display window maintained by the operator module. Visualization data may be of type text, signal, or graphic.