Skip to content

XML configuration files reference

Frederic Simard edited this page Nov 17, 2016 · 5 revisions

XML files are used to define software configuration on run-time. The benefit of using these files is that processes behavior can be changed without requiring to be rebuilt. While XML files provide alot of flexibility, the xmls themselves are not stable, yet, as many features remain to be incorporated or will be changed. Nevertheless, we decided to write down a reference guide to understand what the various fields are used for and list the range of values.

Keep in mind, that the xmls will be revised on a periodic basis as new features get implemented.

Data interface configuration

  • Field: <debug>
    Descr: not used, reserved for code debugging
    Possible values:
    TRUE, enables debugging mode
    FALSE, disables debugging mode

  • Field: <device>
    Descr: defines the hardware that is connected to this interface
    Possible values:
    MUSE, Interaxon Muse headband
    FAKE_MUSE, a stub for the Interaxon Muse that generates fake data
    OPENBCI, the OpenBCI system, will be supported soon

  • Field: <keep_alive>
    Descr: indicate whether a "keep_alive" message needs to be posted to keep the device alive. (Will be removed eventually and automated device with device selection)
    Possible values:
    TRUE, a "keep_alive" is required
    FALSE, a "keep_alive" is not required

  • Field: <nb_data_channels>
    Descr: Number of data channels on the acquisition system, will be updated soon.
    Possible values:
    4, if using the Muse
    8, if using the OpenBCI

  • Field: <remote_addr>
    Descr: contains the bluetooth MAC address of the device to be paired
    Format:
    XX:XX:XX:XX:XX:XX, bluetooth MAC address, discover with hcitool scan utils

  • Field: <output_format>
    Descr: Defines how the data will be outputed from the data_interface
    Possible values:
    CSV, Column Separated Values, data dumped in a text file
    SHM, shared memory output, buffer to other processes

  • Field: <shm_key>
    Descr: active if SHM selected. The key to link with shared memory
    Format:
    XXXX, 4 digits integer, unique on the system

  • Field: <sem_key>
    Descr: active if SHM selected. The key to link with semaphore array
    Format:
    XXXX, 4 digits integer, unique on the system

  • Field: <window_size>
    Descr: Length of the buffer, this amount of sample is taken in, before the reader is notified. Implements the window of acquisition functionnality. This feature hasn't been tested extensively, values given as guidelines Possible values:
    55-250 (Muse, 110 recommended)

  • Field: <nb_pages>
    Descr: Depth of the buffer, this will be update eventually to accomodate for overlapping windows.
    Possible values:
    2

Data preprocessing configuration

  • Field: <debug>
    Descr: not used, reserved for code debugging
    Possible values:
    TRUE, enables debugging mode
    FALSE, disables debugging mode

  • Field: <data_source>
    Descr: Defines where the data comes from.
    Possible values:
    SHM, Shared memory buffer, dumped by another process
    FAKE_DATA, use an internal fake data generator to stub data source

  • Field: <rd_shm_key>
    Descr: active if SHM selected. The key to link with shared memory of the input data buffer
    Format:
    XXXX, 4 digits integer, unique on the system

  • Field: <nb_channels>
    Descr: Number of channels in the data stream
    Possible values:
    1-128 (Muse: 4 recommended)

  • Field: <window_width>
    Descr: Width of the acquisition window.
    Possible values:
    55-250 (Muse: 110 recommended)

  • Content of the feature vector, each field is TRUE or FALSE, whether it needs to be included in the feature buffer:
    <timeseries>, TRUE to include the raw data
    <fft>, TRUE to compute and include the fast fourier transform terms
    <power_alpha>, TRUE to compute and include the absolute power in the alpha band
    <power_beta>, TRUE to compute and include the absolute power in the beta band
    <power_gamma>, TRUE to compute and include the absolute power in the gamma band

  • Field: <feature_dest>
    Descr: Defines where the features will be outputed from the data_preprocessing
    Possible values:
    CSV, Column Separated Values, features dumped in a text file
    SHM, shared memory output, buffer to other processes

  • Field: <wr_shm_key>
    Descr: active if SHM selected. The key to link with shared memory of the output feature buffer
    Format:
    XXXX, 4 digits integer, unique on the system

  • Field: <sem_key>
    Descr: active if SHM selected. The key to link with semaphore array
    Format:
    XXXX, 4 digits integer, unique on the system

Braintone

The xml of the braintone is provided as a reference, but each application can define its own fields.
  • Field: <debug>
    Descr: not used, reserved for code debugging
    Possible values:
    TRUE, enables debugging mode
    FALSE, disables debugging mode

  • Field: <feature_source>
    Descr: Defines where the features comes from.
    Possible values:
    SHM, Shared memory buffer, dumped by another process
    FAKE, use an internal fake feature generator to stub feature source

  • Field: <nb_channels>
    Descr: Number of channels in the features stream
    Possible values:
    1-128 (Muse: 4 recommended)

  • Field: <window_width>
    Descr: Width of the acquisition window.
    Possible values:
    55-250 (Muse: 110 recommended)

  • Content of the feature vector, each field is TRUE or FALSE, whether it needs to be included in the feature buffer:
    <timeseries>, TRUE to include the raw data
    <fft>, TRUE to compute and include the fast fourier transform terms
    <power_alpha>, TRUE to compute and include the absolute power in the alpha band
    <power_beta>, TRUE to compute and include the absolute power in the beta band
    <power_gamma>, TRUE to compute and include the absolute power in the gamma band

  • Field: <buffer_depth>
    Descr: Depth of the feature buffer.
    Possible values:
    2

  • Field: <eeg_harware_present>
    Descr: Indicates whether the application needs to wait for the hardware to be present.
    Possible values:
    TRUE, the application waits on the hardware before starting
    FALSE, the application starts without the hardware

  • Field: <training_set_size>
    Descr: Number of data points to be included in the training set
    Possible values:
    10-40 (20 recommended)

  • Field: <test_duration>
    Descr: Duration of the test phase in seconds, the program quits after
    Possible values:
    60-360 (or more)

  • Field: <avg_kernel>
    Descr: Width of the averaging kernel, the longer, the more more stable, but the less reactive as well
    Possible values:
    1-20 (5-10 recommended)