Differences between revisions 1 and 2
Revision 1 as of 2011-03-08 10:06:56
Size: 98
Comment:
Revision 2 as of 2011-03-16 10:29:13
Size: 5115
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 repective 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 repective 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)