Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2011-03-08 10:06:56
Size: 98
Comment:
Revision 5 as of 2011-03-16 10:38:18
Size: 5332
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
------ In BBCI_APPLY there are two central structures.
Line 3: Line 3:
= Documentation of the BBCI Online System - Description of Data Structures =  1. The 'bbci' structure specifies WHAT should be done and HOW: data acquisition, processing, feature extraction, classification, determining the control signal, and calling the application. It is the input to bbci_apply.
Line 5: Line 5:
------  2. The 'data' structure is used to store the acquired signals, and various steps of processed data, as well as some state information. It is the working variable of bbci_apply.


== Structure BBCI ==

defaults are set in bbci_apply_setDefaults


 bbci.source:: Defines the sources for acquiring signals. struct array with fields:
  .acquire_fcn:: {{{[STRING, default 'acquire_bv']}}}
  .acquire_param:: {{{[CELL ARRAY, default {}]}}}: parameters to acquire_fcn
  .min_blocklength:: {{{[DOUBLE, default 40]}}} minimum blocklength [msec] that should be acquired before dat is passed to further processing (in bbci_apply_setDefaults a variant .min_blocklength_sa is added for convenience.)
  .clab:: {{{[CELL ARRAY of STRING, default {'*'}]}}}
  .log:: see bbci.log. This field specifies, whether source-specific information should be logged (which is reporting when the length of an acquired block is larger than .min_blocklength)

 bbci.marker:: Defines how the acquired markers are stored. struct with fields:
  .queue_length:: Specifies how many markers are stored in the marker queue (see data.marker). The markers in the queue are available for queries and evaluating conditions, see bbci_apply_queryMarker.

 bbci.cont_proc:: Defines how the continuous signals are preprocessed and stored into the ring buffer. struct array with fields:
  .source:: {{{[DOUBLE, default 1]}}}
  .proc:: {{{[CELL ARRAY, one cell per proc function, each CELL is either a STRING, or a CELL ARRAY {FUNC, PARAM}, where FUNC is a STRING and PARAM is a CELL ARRAY of parameters to the function; default {}]}}}
  .buffer_size:: {{{[DOUBLE, default 10000]}}} in msec
  .clab:: {{{[CELL ARRAY of STRING, default {'*'}]}}}

 bbci.feature:: Defines extraction of features from continuous signals. struct array with fields:
  .cont_proc:: {{{[vector of DOUBLE, default 1]}}}
  .ival:: {{{vector [start_msec end_msec]}}}
  .proc:: {{{[CELL ARRAY, one cell per proc function, each CELL is either a STRING, or a CELL ARRAY {FUNC, PARAM}, where FUNC is a STRING and PARAM is a CELL ARRAY of parameters to the function; default {}]}}}

 bbci.classifier:: Specifies classification (model and parameters). struct array with fields:
  .feature:: {{{[vector of DOUBLE, default 1]}}}
  .apply_fcn::
  .C::

 bbci.control:: Defines how to translate the classifier output (and given the event marker) into the control signal. struct array with fields:
  .classifier:: {{{[vector of DOUBLE, default 1]}}}
  .fcn:: {{{[STRING, default '']}}}
  .param:: {{{(if ~isempty(bbci.control.fcn))}}}
  .condition:: defines the events which evokes the calculation of a control signal: [] means evaluate control signal for each data packet that was acquired
     .marker:: CELL of STRINGs (??or rather [vector of DOUBLE]??) specifying the markers that evoke the calculation of a control signal (if
     .interval:: {{{[DOUBLE in msec]}}} (does this option make sense?)
     .overrun:: {{{[DOUBLE in msec]}}} after .marker this amount of signals must
                    have been required (such that epochs of all required
                    .feature can be obtained)

 bbci.feedback:: Defines where and how the control signal is sent. struct array with fields:
  .control:: {{{[vector of DOUBLE, default 1]}}} numbers of the control signals that are send to the feedback application
  .receiver:: {{{'matlab', 'pyff', 'screen', or 'tobi-c'}}}

 bbci.adaptation:: Specifies whether, what and how adaptation should be done. struct with fields
  .active:: {{{BOOL}}} whether adaptation is switched on
  .fcn:: {{{CHAR}}} name of adaptation function ('bbci_adaptation_' is prepended).
  .param:: {{{CELL}}} parameters that are passed to the adaptation.fcn
  .log:: see bbci.log. This field specifies, whether information about adaptation should be logged

 bbci.quit_condition:: Defines the condition when bbcu_apply should quit. struct with fields
  .running_time:: {{{[DOUBLE in sec, default inf]}}}
  .marker:: {{{[CHAR or CELL ARRAY of CHAR, default '']}}}

 bbci.log:: Defines whether and how information should be logged
  .output:: {{{0 (or 'none')}}} for no logging, or {{{'screen'}}}, or {{{'file'}}}, or {{{'screen&file'}}}; {{{'screen'}}} is default if bbci.feeback.receiver is empty, otherwise 0.
  .filebase:: {{{CHAR}}} filename of logfile. May include {{{'$TODAY_DIR'}}} and {{{'$VP_CODE'}}}, which are then replaced by the values of the respective global variables.
  .time_fmt:: {{{CHAR}}} print format of the time, default {{{'%08.3fms'}}}
  .clock:: {{{BOOL}}} specifies whether the clock should also be logged, default 0.
  .classifier:: {{{BOOL}}} specifies whether the classifer should also be logged, default 0.

Optionally further features:
 * remote_control (let parameters be changed over UDP, e.g. by a GUI)?

In BBCI_APPLY there are two central structures.

  1. The 'bbci' structure specifies WHAT should be done and HOW: data acquisition, processing, feature extraction, classification, determining the control signal, and calling the application. It is the input to bbci_apply.
  2. The 'data' structure is used to store the acquired signals, and various steps of processed data, as well as some state information. It is the working variable of bbci_apply.

Structure BBCI

defaults are set in bbci_apply_setDefaults

bbci.source
Defines the sources for acquiring signals. struct array with fields:
.acquire_fcn

[STRING, default 'acquire_bv']

.acquire_param

[CELL ARRAY, default {}]: parameters to acquire_fcn

.min_blocklength

[DOUBLE, default 40] minimum blocklength [msec] that should be acquired before dat is passed to further processing (in bbci_apply_setDefaults a variant .min_blocklength_sa is added for convenience.)

.clab

[CELL ARRAY of STRING, default {'*'}]

.log
see bbci.log. This field specifies, whether source-specific information should be logged (which is reporting when the length of an acquired block is larger than .min_blocklength)
bbci.marker
Defines how the acquired markers are stored. struct with fields:
.queue_length
Specifies how many markers are stored in the marker queue (see data.marker). The markers in the queue are available for queries and evaluating conditions, see bbci_apply_queryMarker.
bbci.cont_proc
Defines how the continuous signals are preprocessed and stored into the ring buffer. struct array with fields:
.source

[DOUBLE, default 1]

.proc

[CELL ARRAY, one cell per proc function, each CELL is either a STRING, or a CELL ARRAY {FUNC, PARAM}, where FUNC is a STRING and PARAM is a CELL ARRAY of parameters to the function; default {}]

.buffer_size

[DOUBLE, default 10000] in msec

.clab

[CELL ARRAY of STRING, default {'*'}]

bbci.feature
Defines extraction of features from continuous signals. struct array with fields:
.cont_proc

[vector of DOUBLE, default 1]

.ival

vector [start_msec end_msec]

.proc

[CELL ARRAY, one cell per proc function, each CELL is either a STRING, or a CELL ARRAY {FUNC, PARAM}, where FUNC is a STRING and PARAM is a CELL ARRAY of parameters to the function; default {}]

bbci.classifier
Specifies classification (model and parameters). struct array with fields:
.feature

[vector of DOUBLE, default 1]

.apply_fcn
.C
bbci.control
Defines how to translate the classifier output (and given the event marker) into the control signal. struct array with fields:
.classifier

[vector of DOUBLE, default 1]

.fcn

[STRING, default '']

.param

(if ~isempty(bbci.control.fcn))

.condition
defines the events which evokes the calculation of a control signal: [] means evaluate control signal for each data packet that was acquired
.marker
CELL of STRINGs (??or rather [vector of DOUBLE]??) specifying the markers that evoke the calculation of a control signal (if
.interval

[DOUBLE in msec] (does this option make sense?)

.overrun

[DOUBLE in msec] after .marker this amount of signals must

  • have been required (such that epochs of all required
  • feature can be obtained)
bbci.feedback
Defines where and how the control signal is sent. struct array with fields:
.control

[vector of DOUBLE, default 1] numbers of the control signals that are send to the feedback application

.receiver

'matlab', 'pyff', 'screen', or 'tobi-c'

bbci.adaptation
Specifies whether, what and how adaptation should be done. struct with fields
.active

BOOL whether adaptation is switched on

.fcn

CHAR name of adaptation function ('bbci_adaptation_' is prepended).

.param

CELL parameters that are passed to the adaptation.fcn

.log
see bbci.log. This field specifies, whether information about adaptation should be logged
bbci.quit_condition
Defines the condition when bbcu_apply should quit. struct with fields
.running_time

[DOUBLE in sec, default inf]

.marker

[CHAR or CELL ARRAY of CHAR, default '']

bbci.log
Defines whether and how information should be logged
.output

0 (or 'none') for no logging, or 'screen', or 'file', or 'screen&file'; 'screen' is default if bbci.feeback.receiver is empty, otherwise 0.

.filebase

CHAR filename of logfile. May include '$TODAY_DIR' and '$VP_CODE', which are then replaced by the values of the respective global variables.

.time_fmt

CHAR print format of the time, default '%08.3fms'

.clock

BOOL specifies whether the clock should also be logged, default 0.

.classifier

BOOL specifies whether the classifer should also be logged, default 0.

Optionally further features:

  • remote_control (let parameters be changed over UDP, e.g. by a GUI)?

IDA Wiki: IDA/BerlinBCI/ToolBox/ToolboxOnline/ToolboxOnlineBbciApplyStructure (last edited 2012-06-21 15:07:33 by BenjaminBlankertz)