Building Experiments

An experiment in BrainStream consists of experiment definition tables, block files and common block files. The experiment may also need user defined functions. The entire experiment is summarized in the BrainStream Project file. In the following, each of these components will be discussed.

Experiment definition tables

The experiment definition tables (.edt) form the core of your BCI experiment. In these tables is specified which actions need to be executed at what time. For each experiment, three different tables are needed: the Actions table, the DataSelection table and the Dictionary table. Together, the experiment definition tables are called the experiment definition file. Brainstream has its own internal editor for creating the tables, however, for backwards compatibility reasons it also supports excel files (.xls extensions only) where each table is put in a different sheet, or a set of separate text files (.txt), one for each table. In the following, the experiment definition tables will be discussed in more detail.

Actions table

Table 1 is an example of an Actions table:

marker time function feval looptick client
mrk1 EVENT fnc1,fnc2      
  1 fnc3      
mrk2,mrk3 EVENT fnc4      

Table 1: Actions table

The first column of the Actions table, the marker column, contains the names of all markers that elicit the execution of certain actions. If actions for the same marker are listed in different rows of the table, the marker name only needs to be specified in the first row. For example, in table 1, the actions for marker mrk1 are specified in two different rows, and the marker column can remain empty for the second of these rows. Multiple markers can be specified, separated by commas. Any of the markers from this list will trigger the execution of the associated actions. For example, in table 1, function fnc4 will be executed whenever either marker mrk2 or mrk3 arrives. The marker column can also contain a reference to another table (see Plug-ins).

The second column (time) specifies at which timepoints, relative to the time of the incoming marker, the actions should be executed. The exact timing of execution can be specified in several ways. The action can be executed directly at marker onset, when a certain amount of data becomes available, some time after the marker, or when another marker arrives (see table 2). For example, table 1 specifies that functions fnc1 and fnc2 are executed at the onset of marker mrk1 whereas function fnc3 takes place one second after marker onset.

EVENT
DATA
a number
another mrk
Executed at marker onset
Executed as data becomes available
Executed number seconds after marker onset
Executed at onset of marker mrk

Table 2: Specifying time of action execution

The third column (function) can contain one or more functions that will be executed in the order in which they appear in the table. So, in table 1, at the onset of marker mrk1, first function fnc1 and then function fnc2 will be executed. One second after the onset of marker mrk1, fnc3 will be executed. A number of BrainStream functions can be used in the function column. Alternatively, you can write your own user defined functions, which will be discussed in detail below.

The next three columns are optional. The feval column allows for specification of any functions that take global variables as input argument, but do not process any of them. The looptick column is optional and serves to define a special function that will be put into a loop by BrainStream, click here for more information on how to use this. The client column can be used to direct execution of functions to another remote Matlab session (see Running BrainStream in Parallel Mode).

Although the order of these first columns in the table is arbitrary, it is best to keep it as described here. All subsequent columns are free to use for an arbitrary number of user defined variables (more on this later).

DataSelection table

Sometimes a marker signals a time point around which data should be collected. For example, if you are building an ERP-based BCI, you might want to collect a certain amount of data after each stimulus. For that purpose, each marker can specify a segment of data that should come along with the event. The DataSelection table indicates which markers call for data selection and also the time period of data selection relative to marker onset.

The DataSelection table consists of a marker column, a begindata column, and an enddata column. Data selection may start before or after onset of the marker, indicated by negative and positive numbers respectively. The end of data selection can be before or after the onset of the marker specified in the marker column, when a new marker arrives (with or without extra timing), or when nothing happens for a specified period of time (timeout). If multiple endtimes, seperated by a comma, are specified, the one that happens first will end the data selection.

marker begintime endtime datasource
mrk1 -0.5 2  
mrk2 0.5 mrk3+1  
mrk4 0 mrk4, mrk5, timeout(3)  

Table 3: DataSelection table

The table above shows an example of a data selection table. The data selection of mrk1 will start half a second before onset of the marker and end 2 seconds after the onset.The data selection of mrk2 will start half a second after the onset of mrk2 and will end one second after marker mrk3 arrives. Marker mrk4 will start data selection immediately and this will end when a new marker mrk4 arrives (in other words, after the first occurrence of marker mrk4, every new marker mrk4 will both end the previous period of data selection and start a new period). This sequence ends when marker mrk5 arrives or when no markers come in for 3 seconds. Note that if ending markers do not set the end of data selection and no timeout is specified, corresponding processing steps (with timepoint DATA) will never execute.

Timing offsets can also be specified in number of samples. In that case, the number should be followed by a '#' symbol (for example, 1024#). Of course, time points that are specified in seconds will also be rounded off to the nearest sample number by BrainStream's internal processing.

The datasource column is optional. If multiple data sources are used in the experiment, the datasource column specifies from which source the data should be collected. If only one data source is involved, BrainStream will automatically collect data from this single source only.

Dictionary table

Markers are represented as numbers in for example the acquisition hardware or stimulus presentation modules, whereas in BrainStream they are represented as names (strings). The Dictionary table is required to translate incoming markers to their associated names.

The first three columns of the Dictionary table are fixed. In the marker column the marker names are specified. The second column specifies the marker type. The marker can for example be a stimulus or a response marker. The value column specifies the number with which the marker is represented outside BrainStream.

The substitute and datasource columns are optional. More information about the substitute column can be found in the Plug-in section. If multiple data sources are used in the experiment, the datasource column specifies for which data source the dictionary information is meant. If only one datasource is involved, this column can be left out and BrainStream will apply the definitions to the single data source.

marker type value substitute datasource
tone stimulus 10    
voice stimulus 11    
button response 128    

Table 4: Dictionary table

Preventing conflicts with plug-in tables

BrainStream supports the use of Plug-in tables. An example of a plug-in table is the plug-in for bad channel detection. Alternatively, it is possible to build your own plug-in table. Any plug-in itself consists of an Action, DataSelection and Dictionary table.

When BrainStream is started, all experiment definition tables that are used in the experiment - including the plug-in tables - are combined in a process called table expansion. This means that all Action tables will be integrated into a single Action table, and the same is true for the DataSelection and Dictionary tables. Importantly, the information in the individual tables shoud not conflict. For example, you should prevent double definitions of marker names or numbers.

User defined functions and variables

In the Actions table, certain actions are assigned to markers. You can define the actions directly in the table, but it is also possible to specify actions by adding user defined functions to your table. The functions that you write may need certain variables as input. An arbitrary number of columns in the Action table can be used for these user defined variables.

If a function needs a user defined variable, you first need to get it from the global variables. This is done by putting a ‘get’ statement in the corresponding cell. For example, consider the following Actions table:

marker time function feval looptick client var1 ........ varN
mrk1 EVENT my_fnc1       get ........  
mrk2 2 my_fnc2         ........ get,put

At the onset of marker mrk1, user defined function my_fnc1 will be executed. This user defined function needs the user defined variable var1 as input. In order to make this variable available to my_fnc1, a 'get' statement is placed in the var1 column. Note that variable var1 is not available to the user defined function my_fnc2 that is executed after marker mrk2, as no 'get' statement is present in the var1 column after this function.

User defined functions must be written in the following format:

event = my_function(event,c1,c2,...)

The input and output argument 'event' is obligatory. 'Event' is a Matlab type structure variable. The fields of this structure contain copies of the current content of the variables with a 'get' statement in the table. In the above example, var1 was made available to function my_fnc1 with a 'get' statement. Thus, the my_fnc1 input argument 'event' will contain the field event.var1, which holds a copy of var1. In contrast, the input argument 'event' of function my_fnc2 will not contain the field event.var1 (no 'get' statement in the Actions table), but it will have a field called event.varN, which contains a copy of variable varN.
The additional input arguments (c1, c2, ...) are optional. You can enter constants there, if your function needs them.

Your user defined function might change the content of some the variables you use as input. If you want to save these changes, you can place a 'put' statement in the corresponding cell in the Actions table, which updates the modified variables to the global variables. In the example above, changes that my_fnc2 makes to varN are saved, but changes that my_fnc1 makes to var1 are not (no 'put' statement). For more information about loading, modifying and saving user defined variables, see Modifying variables.

Block files and common block files

To initiate your experiment in BrainStream, you need to compose one or more initialization run files, also called block files (.blk). Each block file contains or refers to all information needed to initiate the particular block of the experiment. For example, BrainStream needs to know to which data acquisition source it is connected, where to store output and where the experiment definition tables are located. The format of the block files is according to the Windows .ini file style with topics enclosed in brackets and subsequent lines to define keys that belong to this topic. If another bracketed line is encountered, a new topic is started and additional lines will add keys to this new topic. The notation of the topics and keys is in Matlab style, which means that every valid Matlab statement is possible here. For example, Matlabs comment character (%) can be utilized. An example of a block file is shown below. In this example, all minimally required topics with their keys are shown.

[DataSources]
eeg = 'buffer://localhost:1972:biosemi_active2'

[eeg]
% keys specific to the eeg data source 

[biosemi_active2] 
sendMarkerFunction = 'sndMidiMarker'

[Files]
ExperimentDefinitionFile = '/Volumes/Data/ExpDefs/SubRhythm/SubjectiveRhythm.xls'
OutFolder = '/Volumes/Data/Experiment/'

[Experiment]
Block = 'subjective_rhythm'

Additional possible topics with their keys are listed here? .

In addition to the listed topics and keys you can add your own topics and keys, as long as they are not used by BrainStream itself. The advantage is that these items are readily accessible for your own written user defined functions throughout the whole experiment. Information in the block files can be accessed using the bs_get_blockvalue function.

If an experiment consists of several blocks, the topic and key combinations which are the same for all blocks can be put in a common block file. The structure of a common block file is the same as other block files, but settings specified in a common block file will be applied to all blocks. For example, information that is specific to the lab in which the experiment takes place could be put in a common block file. The advantage is that you do not have to specify the same information more than once and if you change the setting in the common block file it will be applied to all blocks.

BrainStream project files

References to all block files and common block files can be put together in a single seperate 'BrainStream Project' (.bsp, or .exp for older versions) file with topics Blocks and CommonBlocks. Both topics define the Files key, in which a cell array of block file names defines which block files take part in the experiment. This single file then defines your whole BCI experiment. For example, if your experiment is defined by three functional blocks, namely train.blk, classifier.blk and feedback.blk, and one common block file lab1.blk, the following project file would be sufficient to include them all at once when starting BrainStream:

[Blocks]
Files = {'/Volumes/my_experiments/my_BCI/train.blk', ...
         '/Volumes/my_experiments/my_BCI/classifier.blk', ...
         '/Volumes/my_experiments/my_BCI/feedback.blk'}
[CommonBlocks]
Files = {'lab1.blk'}  


This topic: BrainStreamDocs > BrainStreamDocs?  > DocsSectionsBuildingExperiments
Topic revision: r7 - 26 Sep 2011 - 10:05:09 - MarjoleinVanDerWaal
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback