Technical Reference:System Design: Difference between revisions
No edit summary |
|||
| (28 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
==Overview== | ==Overview== | ||
While BCIs can differ widely in the nature of the physiological components they | |||
that | use, the signal processing they perform, the feedback they provide, or | ||
communicate with each other. These modules are called ''Source'' , | the underlying training and operation paradigm, they all need the same four | ||
''Signal Processing'' , ''Application'' , and | elements: data collection, signal processing, an output device and manual or | ||
''Operator'' . We will | automatic parameterization and configuration. Therefore, it seems to be a | ||
natural choice to partition the system into four modules with respect to | |||
functionality. | |||
It is conceivable that for certain BCIs, the chosen decomposition might be | |||
overkill, or even unfavorable, but still these modules seem to be the most appropriate | |||
for a variety of systems. | |||
In accordance with this decomposition, BCI2000 consists of four modules that communicate with each other. (See Figure 1.) These modules are called ''Source'', ''Signal Processing'', ''Application'', and ''Operator''. We will | |||
refer to the three modules Source, Signal Processing and Application | refer to the three modules Source, Signal Processing and Application | ||
together as | together as | ||
''core modules'' . | ''core modules''. | ||
[[Image:BCI2000 SysDes_Modules.png|center|thumb|591px|Fig. 1 The functional modules and their interfaces]] | |||
In a binary distribution, the four modules correspond to executables. | |||
For modules other than the operator module, executable file names vary, reflecting specializations of the generic modules. | |||
{|border="1" | |||
|+ Example Configuration | |||
! Module Name !! Executable File Name !! Notes | |||
|- | |||
| Operator || Operat.exe || | |||
|- | |||
| Source || gUSBamp.exe || data acquisition from the gUSBamp g.tec amplifier | |||
|- | |||
| Signal Processing || ARSignalProcessing.exe || auto-regressive spectral estimation | |||
|- | |||
| Application || CursorTask.exe || moving a cursor by brain activity | |||
|} | |||
==Core-Operator Communication== | ==Core-Operator Communication== | ||
The same communication protocol is used between each of the three core | The same communication protocol is used between each of the three core | ||
modules | modules | ||
and the operator module. Although it can be implemented on top of any | and the operator module. Although it can be implemented on top of any | ||
transport | transport | ||
protocol, | protocol, the communication protocol assumes the reliability of TCP (i.e., the protocol does | ||
not support | not support | ||
acknowledgements or packet sorting or any other means of error | acknowledgements or packet sorting or any other means of error | ||
correction). | correction). | ||
Communication consists of [[BCI2000 | Communication consists of [[Technical Reference:BCI2000 Messages|messages]] that are sent and received | ||
asynchronously | asynchronously | ||
between any core module and the operator module. | between any core module and the operator module. | ||
Below, an overview of message types is given. For details about specific messages, refer to the [[BCI2000 | Below, an overview of message types is given. For details about specific messages, refer to the [[Technical Reference:BCI2000 Messages]] page. | ||
===Status Information Messages=== | ===Status Information Messages=== | ||
[[ | [[Technical Reference:BCI2000 Messages#Status Message|Status Messages]] are used to communicate errors and to convey status | ||
information (e.g., the operator module may display the remaining | information (e.g., the operator module may display the remaining disk space on the Source | ||
module's machine. | module's machine). | ||
===Parameter Messages=== | ===Parameter Messages=== | ||
These messages transport [[ | These messages transport [[BCI2000 Glossary#Parameter|Parameters]] carrying configuration information. | ||
The operator module receives parameter messages from core modules, which | The operator module receives parameter messages from core modules, which enable it to display parameters in a configuration dialog, and to save parameters to, and load them from a [[Technical Reference:Parameter File|parameter file]]. | ||
===State Messages=== | ===State Messages=== | ||
As a generalization of event markers, the core modules and the operator module use messages containing [[BCI2000 Glossary#State|States]] to | |||
communicate in the system initialization phase, | communicate in the system initialization phase, | ||
as well as during system performance and | as well as during system performance and | ||
| Line 46: | Line 63: | ||
===Visualization Messages=== | ===Visualization Messages=== | ||
[[ | [[BCI2000 Glossary#Visualization|Visualization]] messages are sent from core modules to the operator module, which in turn displays their content to the operator user. | ||
These messages may contain signal data for graphical display, or text to be displayed in a log window. | These messages may contain signal data for graphical display, or text to be displayed in a log window. | ||
A core module may also configure details of the display sending configuration messages. | A core module may also configure details of the display sending configuration messages. | ||
===System Command Messages=== | ===System Command Messages=== | ||
[[ | [[Technical Reference:BCI2000 Messages#System Command|System Commands]] are meta-messages used to control the behavior of individual modules by switching their internal state. Typical system commands are <tt>EndOfParameter</tt> and <tt>EndOfState</tt>, to terminate a list of parameter or state messages. | ||
The nature of these system commands is defined by the specific | The nature of these system commands is defined by the specific | ||
implementation of | implementation of | ||
| Line 57: | Line 74: | ||
==Inter-Core Communication== | ==Inter-Core Communication== | ||
Unlike the bidirectional communication between core modules and the | Unlike the bidirectional communication between core modules and the | ||
operator | operator | ||
| Line 67: | Line 83: | ||
===State Vector Messages=== | ===State Vector Messages=== | ||
A [[ | A [[BCI2000 Glossary#State Vector|State Vector]] is a data structure consisting of a series of ''StateVectorLength'' | ||
subsequent bytes, representing an overall system state that is saved into a data file along with each | subsequent bytes, representing an overall system state that is saved into a data file along with each sample of data. | ||
State vector data is always transmitted before the brain signal or control signal. | |||
brain | |||
signal or control signal. | |||
===Brain Signal Messages=== | ===Brain Signal Messages=== | ||
From source to signal processing module, selected channels from the brain signal are transmitted as 32-bit floating point numbers calibrated into microvolts. | From the source to the signal processing module, selected channels from the brain signal are transmitted as 32-bit floating point numbers calibrated into microvolts. | ||
The brain signal format is similar to the data format used for graphic visualization messages. | The brain signal format is similar to the data format used for graphic visualization messages. | ||
===Control Signal Messages=== | ===Control Signal Messages=== | ||
From signal processing to application module, signal messages transfer decoded rather than raw brain signals. In both cases, the same kind of message is used. | From the signal processing to the application module, signal messages transfer decoded rather than raw brain signals. In both cases, the same kind of message is used. | ||
Typically, control signals consist of two or three channels carrying signals with zero mean and unit variance. | Typically, control signals consist of two or three channels carrying signals with zero mean and unit variance. | ||
==See also== | |||
[[Technical Reference:BCI2000 Messages]], [[Technical Reference:Core Modules]] | |||
[[Category:Specification]] | |||
Latest revision as of 14:16, 18 October 2008
Overview
While BCIs can differ widely in the nature of the physiological components they use, the signal processing they perform, the feedback they provide, or the underlying training and operation paradigm, they all need the same four elements: data collection, signal processing, an output device and manual or automatic parameterization and configuration. Therefore, it seems to be a natural choice to partition the system into four modules with respect to functionality. It is conceivable that for certain BCIs, the chosen decomposition might be overkill, or even unfavorable, but still these modules seem to be the most appropriate for a variety of systems.
In accordance with this decomposition, BCI2000 consists of four modules that communicate with each other. (See Figure 1.) These modules are called Source, Signal Processing, Application, and Operator. We will refer to the three modules Source, Signal Processing and Application together as core modules.

In a binary distribution, the four modules correspond to executables. For modules other than the operator module, executable file names vary, reflecting specializations of the generic modules.
| Module Name | Executable File Name | Notes |
|---|---|---|
| Operator | Operat.exe | |
| Source | gUSBamp.exe | data acquisition from the gUSBamp g.tec amplifier |
| Signal Processing | ARSignalProcessing.exe | auto-regressive spectral estimation |
| Application | CursorTask.exe | moving a cursor by brain activity |
Core-Operator Communication
The same communication protocol is used between each of the three core modules and the operator module. Although it can be implemented on top of any transport protocol, the communication protocol assumes the reliability of TCP (i.e., the protocol does not support acknowledgements or packet sorting or any other means of error correction). Communication consists of messages that are sent and received asynchronously between any core module and the operator module. Below, an overview of message types is given. For details about specific messages, refer to the Technical Reference:BCI2000 Messages page.
Status Information Messages
Status Messages are used to communicate errors and to convey status information (e.g., the operator module may display the remaining disk space on the Source module's machine).
Parameter Messages
These messages transport Parameters carrying configuration information. The operator module receives parameter messages from core modules, which enable it to display parameters in a configuration dialog, and to save parameters to, and load them from a parameter file.
State Messages
As a generalization of event markers, the core modules and the operator module use messages containing States to communicate in the system initialization phase, as well as during system performance and for system termination.
Visualization Messages
Visualization messages are sent from core modules to the operator module, which in turn displays their content to the operator user. These messages may contain signal data for graphical display, or text to be displayed in a log window. A core module may also configure details of the display sending configuration messages.
System Command Messages
System Commands are meta-messages used to control the behavior of individual modules by switching their internal state. Typical system commands are EndOfParameter and EndOfState, to terminate a list of parameter or state messages. The nature of these system commands is defined by the specific implementation of the modules.
Inter-Core Communication
Unlike the bidirectional communication between core modules and the operator module, communication within the core modules is unidirectional. The initial setup determines the exact nature of this communication and data is transmitted with the same protocol as described above.
State Vector Messages
A State Vector is a data structure consisting of a series of StateVectorLength subsequent bytes, representing an overall system state that is saved into a data file along with each sample of data. State vector data is always transmitted before the brain signal or control signal.
Brain Signal Messages
From the source to the signal processing module, selected channels from the brain signal are transmitted as 32-bit floating point numbers calibrated into microvolts. The brain signal format is similar to the data format used for graphic visualization messages.
Control Signal Messages
From the signal processing to the application module, signal messages transfer decoded rather than raw brain signals. In both cases, the same kind of message is used. Typically, control signals consist of two or three channels carrying signals with zero mean and unit variance.
See also
Technical Reference:BCI2000 Messages, Technical Reference:Core Modules