User Reference:BCI2000Certification

Introduction

BCI2000 v2.0 and higher includes a certification procedure that can determine whether a computer system is capable of running all or some BCI2000 applications. Because BCI2000 does not have a standardized hardware configuration, i.e., it can run on potentially any PC, this testing procedure is capable of running on any PC with BCI2000, with the results reporting which standard BCI2000 applications meet the minimum timing requirements. Different configurations are included in the certification procedure to test a range of likely setups for a given application, in which timing characteristics such as the sampling rate, inter-stimulus intervals, and stimulus duration, and other parameters, such as the number and size of the stimuli, are changed for each configuration.

This document serves as the instruction manual for using the certification procedure, and describes how the procedure works to determine the timing characteristics of the BCI2000 system. The primary use for the certification procedure is to determine if the PC configuration used with BCI2000 is capable of running the core BCI2000 system, which is comprised of:

• Support for the the g.tec series of amplifiers, including the g.USBamp, g.MOBIlab, and the g.MOBIlab+ (bluetooth) amplifiers.
• The AR, P3, FFT, and Matlab signal processing modules.
• The CursorTask, P3Speller, and StimulusPresentation application modules.

Additionally, due to the extensibility of BCI2000, researchers who develop custom algorithms and applications, or use amplifiers not made by g.tec, can use the certification procedure to determine whether their custom modules are capable of running on a particular PC configuration.

The certification procedure works by comparing the differences in time of when BCI2000 expects an event to occur to when that event actually occurred. These events include a change in the display, an audio output through the system speakers, or an EEG sample being stored in the amplifier buffer. The times at which such events occur are recorded with the amplifier and stored in a data file. Changes in the display are found using an optical sensor in combination with the g.TRIGbox. The g.TRIGbox is a signal conditioner that generates trigger pulses for various sensors or input signals. When the sensor exceeds a threshold, the g.TRIGbox outputs a digital signal which is recorded on the amplifier. A similar procedure is used for audio detection: the sound output from the PC is input to the g.TRIGbox, and when the volume exceeds threshold, a high digital signal is output and recorded by the amplifier. This information can be used because BCI2000 stores a time-stamp for every event during an experiment. The difference between a time-stamp value and the time that the recorded event changes values are compared to find the latency for that particular event.

These latencies can be affected by many external influences, including hardware deficiencies (such as low RAM, slow CPU speed, or a video card of low quality), and other software running in the background while the experiment is being run.

Latencies

Briefly, the different latencies inherent in the BCI2000 system include amplifier latency, processing latency, output latency, and the sum of these, the system latency. Additionally, the block duration jitter will be measured. Figure \ref{fig:timeline} provides a timeline of events that occur within a single block of data, with significant time points labeled. This figure provides an accurate account of the order in which events occur within a block of data, although the time intervals are not necessarily to scale.

Timeline of events. Time intervals are not to scale.

Defining Latencies

Amplifier Latency

Amplifier Latency is the minimum delay between the time that a signal is presented at the amplifier input, to when it has been acquired in the source module. Depending on configuration, this may comprise physical signal delay in the amplifier, digitization, transmission from the amplifier to the PC, and processing time inside a hardware driver. That minimum delay occurs for the last sample of a data block, which, unlike its preceding samples in the same block, will spend only a minimum time in hardware and software buffers. In Timeline,

Amplifier latency = $t_0-t_{-1}$.

For amplifiers connected via bandwidth-limited serial interfaces, transmission latency may have a measurable impact on amplifier latency, depending on the hardware. When using USB 2.0, as is the case for the g.USBamp, transmission latency may generally neglected, as illustrated by the following example: USB 2.0 has a maximum transmission rate of 480 Mbit/s. If we are acquiring 16 channels of 32-bit data, and transmitting in blocks of 16 samples, this is 8192 bits of data; at USB 2.0 speed, this should take roughly 17 $\mu$s to transfer. However, a more realistic approximation for USB 2.0 speeds is 240 Mbit/s, which increases the transfer delay to 34 $\mu$s. For sampling rates below 30 kHz, this is less than a single sample's duration.

In addition to amplifier latency, system performance will be influenced by buffering latency. Buffering latency is dependent on the sample block buffer size: When a data sample is digitized, it is not immediately transferred to the PC, but is stored in memory on the amplifier. The PC then makes the appropriate request to the amplifier, and a block of data is transferred all at once to reduce the processing load. This implies that a signal that is digitized at the start of the buffer must wait until the buffer is full to be read into the PC. For example, if the sample block size is 16 samples, the first sample must wait 15 more samples before it can be used in the application. Fortunately, this latency is always known, and can be reduced with a higher sampling rate and/or smaller block sizes, assuming the PC can handle the increased overhead. Buffering latency does not affect the acquisition-to-display latency, because processing occurs immediately after a block's last sample, which is not affected. Still, it is an important factor to keep in mind, because a large sample block size and/or a small sample rate will decrease the refresh rate for the application (e.g., at a sample rate of 256 Hz and a sample block size of 128 samples, the application will only be refreshed every 0.5 s.)

Processing Latency

Processing Latency is the total time it takes for the data to be processed by all BCI2000 modules (SignalSource, SignalProcessing, and Application).

Processing latency = $t_4-t_0$.

Processing latency strongly depends on CPU speed, and if this latency becomes too large, high CPU load will probably be the cause, implying decreased or unsuitable BCI2000 performance.

Output Latency

Output Latency is the latency from the time that the Application module issues a command to change the display or issue a sound (or another output), to the time that this output actually occurs.

Output latency = $t_5-t_4$.

System Latency

System Latency is the minimum time interval between a change in amplifier input, and a causally related change in application output. This is the sum of the above latencies, Amplifier, Processing, and Output.

System latency = $t_5-t_{-1}$.

Block Duration, Block Duration Jitter

Block Duration is the time interval between adjacent blocks of data, normalized to the ideal duration of a data block as determined from sampling rate and sample block size:

Block Duration = $\frac{t_8-t_0}{\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{o}\mathrm{c}\mathrm{k}\mathrm{S}\mathrm{i}\mathrm{z}\mathrm{e}/\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{R}\mathrm{a}\mathrm{t}\mathrm{e}}$.

When the system operates in real time, mean Block Duration will always be 1. Measuring Block Duration has the purpose of obtaining Block Duration Jitter as its standard deviation.

The procedures that will be used to measure the quantities introduced, follow below. Figure \ref{fig:overview} gives an overview of the system latencies with the testing equipment shown.

Data flow during timing measurement. Event labels correspond to those in Image:TimeLine.png

Measuring Latencies

Measuring Amplifier Latency

In TimeLine, Amplifier Latency is the time interval between the sampling of a data block's last sample, and its acquisition into the source module's data buffer:

$\mathrm{A}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}=t_0-t_{-1}$

To measure this latency, the SignalSource module will set a digital output on the amplifier to a high value at time $t_0$ immediately following data acquisition, as indicated in Overview. The digital output level is 3.3 V, so a voltage divider may required to attenuate the signal level to the range of amplifier input. This signal is then recorded on an input channel on the amplifier (time $t_1$).

In the recorded data, we may then identify $t_{-1}$, which is the beginning of sample block $n$, by its sample offset, which also coincides with BCI2000 state changes. $t_1$ may be identified by a change in the recorded signal, occurring in the channel that was connected to the digital output during measurement. Neglecting the very small delay between issuing the change in the digital output at $t_0$, and the changed signal appearing at the amplifier's input at time $t_1$, we measure (Signal Source Latency)

$\mathrm{A}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}\approx t_1-t_{-1}.$

Latency of the Amplifier, using a digital trigger software output and encoded analog input.

Measuring Processing Latency

Processing latency is defined as the amount of time that it takes for the computer to process the data from the time that it has been acquired by the source module, to when the application module's output is changed. In TimeLine and Overview, this is the time from $t_0$ to $t_4$. Processing latency is calculated using two timestamps saved with every block of data, $SourceTime$ and $StimulusTime$. $SourceTime$ is saved at $t_0$, immediately following data acquisition in the SignalSource module, and $StimulusTime$ is saved at $t_4$ immediately following application presentation in an application module. Therefore, processing latency for each block of data is calculated as the difference between time stamps:

$\mathrm{P}\mathrm{r}\mathrm{o}\mathrm{c}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}=\mathrm{S}\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{u}\mathrm{l}\mathrm{u}\mathrm{s}\mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}-\mathrm{S}\mathrm{o}\mathrm{u}\mathrm{r}\mathrm{c}\mathrm{e}\mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}=t_4-t_0.$

Measuring Application Display/Sound Output Latency

There are many possible application output types, including visual (i.e., the computer screen), audio, or mechanical (e.g., a robotic arm). The core BCI2000 system primarily uses visual and audio output, and so the default testing system will focus on these.

Both visual and audio output can be measured using the g.TRIGbox signal conditioner, which accepts inputs from optical sensors, microphones, or any other input. The user sets a threshold for the input signals, and the g.TRIGbox outputs a digital pulse whenever this threshold is exceeded. This output is then recorded back into the amplifier system, so that the analysis program can measure the response times for each output.

Again, neglecting $t_1-t_0$ as well as $t_6-t_5$, we identify event $t_0$ by a change in the data channel connected to the amplifier's digital output, and event $t_5$ by a change in the data channel connected to the g.TRIGbox, and compute their difference. Also, both events are affected by Amplifier Latency in the same way, so we may ignore Amplifier Latency, and have

$\begin{array}{c}\mathrm{O}\mathrm{u}\mathrm{t}\mathrm{p}\mathrm{u}\mathrm{t}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}=t_5-t_4=(t_5-t_0)-(t_4-t_0)=(t_5-t_0)-\mathrm{P}\mathrm{r}\mathrm{o}\mathrm{c}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}.\end{array}$

Application output latency.

Measuring System Latency

As defined above, System Latency is the sum of Amplifier Latency, Processing Latency, and Output Latency. It may be measured

1. directly, by identifying $t_{-1}$ as the beginning of a data block by its sample index, and $t_6\approx t_5$ by the signal change in the channel connected to the g.TRIGbox, and then calculating
   $\text{<mrow data-mjx-texclass="ORD">SystemLatency</mrow>}=t_5-t_{-1}$,
2. or indirectly, by using the previously measured quantities
   $\text{<mrow data-mjx-texclass="ORD">SystemLatency</mrow>}=\mathrm{A}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{f}\mathrm{i}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}+\mathrm{P}\mathrm{r}\mathrm{o}\mathrm{c}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}+\mathrm{O}\mathrm{u}\mathrm{t}\mathrm{p}\mathrm{u}\mathrm{t}\mathrm{L}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}$.

Measuring Block Duration

Block Duration is measured as the time between adjacent blocks of data, divided by the theoretical ideal value, which is the sample block duration. For the actual measurement, we use the difference between subsequent $\text{<mrow data-mjx-texclass="ORD">SourceTime</mrow>}$ time stamps which are recorded at $t_0$ and $t_8$ in Timeline:

$\mathrm{B}\mathrm{l}\mathrm{o}\mathrm{c}\mathrm{k}\mathrm{D}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=\frac{t_8-t_0}{\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{o}\mathrm{c}\mathrm{k}\mathrm{S}\mathrm{i}\mathrm{z}\mathrm{e}/\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{R}\mathrm{a}\mathrm{t}\mathrm{e}}=\frac{\mathrm{\Delta }\mathrm{S}\mathrm{o}\mathrm{u}\mathrm{r}\mathrm{c}\mathrm{e}\mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}}{\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{o}\mathrm{c}\mathrm{k}\mathrm{S}\mathrm{i}\mathrm{z}\mathrm{e}/\mathrm{S}\mathrm{a}\mathrm{m}\mathrm{p}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{R}\mathrm{a}\mathrm{t}\mathrm{e}}$

Latency Calculation Overview

Latencies are calculated by comparing changes in a BCI2000 state value to changes in a recorded signal. The analysis program follows these general steps in calculating the various latencies:

1. Determine which threshold values to use based on the thresh definition in the BCI2000Certification.cfg file, which defines a threshold based on the amplifier used. For example, the g.USBamp has an input range of -250 mV to + 250 mV, and the g.TRIGbox outputs from 0 to 200 mV, so the threshold used is about 12.5 mV.
2. Traverse the state values for a selected state and find where the state changes from 0 to a given value (or any value). The sample at which this occurs is saved for later use in $stateChangePos$.
3. When this occurs, start looking through $Signa{l}_{norm}$ to find when a rising edge exceeds the determined threshold value. The sample at which this occurs is saved in $sigChangePos$.
4. The latency for the $n$th state change is calculated as:

   $\begin{array}{c}latenc{y}_n=\frac{sigChangePo{s}_n-stateChangePo{s}_n}{SampleRate}\end{array}$

   and is stored in an array.

5. Once the entire state vector is traversed, the mean, standard deviation, minimum and maximum values for this latency are calculated and reported.

Getting Started With the Default Tests

This section provides step-by-step instructions on running the default certification procedure. Note that some cables must be assembled before the testing can be done; see Appendix \ref{sec:ampcables} for information on assembling the cables.

Set Default Parameters

Using a text editor, open the CertificationMain.prm file in the BCI2000/tools/BCI2000Certification/parms/ folder. Many of the settings should be left alone, except for some of the following cases.

Sampling Rate

This is set to 512 by default. This can be changed to another value that will apply to all tests, except those that explicitly override it in their own parameter file.

Display parameters

These are on the lines that begin with Application:Window. For many labs, the default settings should work fine; the window is setup to appear in the top-left corner of the main window (WindowLeft= 0 & WindowTop= 0 ), and is 800 wide by 800 pixels tall (WindowWidth= 800 & WindowHeight= 800 ).

Users with a dual-screen configuration may wish to change this so that the BCI2000 window is on the secondary monitor; to do so, the WindowLeft parameter should be changed, which depends on the resolution and orientation of both monitors. For example, if the 2nd monitor is to the right of the primary monitor, and both monitors have a resolution of 1280x1024 pixels, setting WindowLeft to 1280 will place the window on the 2nd monitor. Similarly, if the 2nd monitor is to the left of the primary monitor, setting WindowLeft to -1280 will accomplish the same thing. If the monitors have different resolutions (e.g., monitor 1 is 1600x1200 and monitor 2 is 1024x768, located to the right of the 1st monitor), the position should change accordingly. For example, in this scenario, to set the window to the right of the main window, set WindowLeft to 1600 . Finally, set the WindowWidth & WindowHeight to appropriate values for full-screen, if desired. To summarize, for the dual-screen case in which monitor 1 is 1600x1200 pixels, and monitor 2, to the right of 1, is 1024x768 pixels, and the BCI2000 window should be full-screen on monitor 2, the parameters should look like:

Application:Window int WindowWidth= 1024 ...
Application:Window int WindowHeight= 768 ...
Application:Window int WindowLeft= 1600 ...
Application:Window int WindowTop= 0 ...
Note that nothing following the ... needs to be changed above in the parameter file.

Connect the Amplifier to the Trigger Box, and Attach Sensors

Connections overview

This section describes the steps for connecting the necessary hardware. Refer to the Connections Overview figure above for additional information; each step is numbered in this figure.

1. Connect the amplifier to the computer; the supported g.tec amps are connected via USB, RS232, or Bluetooth.
2. Connect the Digital I/O cable (see \ref{sec:digicable}) to the amplifier on the Digital I/O port.
3. Connect the reference and ground wires from the assembled amplifier cables to the amplifier reference and ground connections.
4. Connect the amplifier cables with the safety connectors into channels 1, 2, and 3 on the g.USBamp.
5. Connect the digital output line to the channel 1 amplifier cable.
6. Connect the A output from the trigger box to the channel 2 amplifier cable.
7. Connect the B output from the trigger box to the channel 3 amplifier cable.
8. Connect the optical sensor plug to the g.TRIGbox, using the optical sensor input channel A.
9. Connect the computer audio output using a stereo cable to the g.TRIGbox, using the high-level input channel B.

Setup Sensor Thresholds

The audio and optical sensors each have a threshold setting on the g.TRIGbox, along with an LED indicating whether the current input is above threshold for each channel. At rest, each trigger should be off; if any is on, turn the threshold knob counter-clockwise until the LED is off.

Audio Threshold

To set the audio threshold, set audio volume on the computer to maximum. On Windows, to make this process easier in the future, go to the Start menu, click the Control Panel, and go to Sounds. In the Sound window, click the box that puts the volume icon in the task bar. A small speaker should now appear in the bottom-right of the screen in the task bar. Click this icon, and slide the volume up to the max; when you click on this slider, Windows emits a short beep to give an idea of the volume level, which can be used to set the threshold. To do so, make sure that the stereo audio cable is plugged into the g.TRIGbox, and click the slider to emit a sound, checking that the green LED is flashing when you click the slider. If it is not, turn the threshold knob for channel B counter-clockwise, and click the slider again. If it is still not working after several tries, unplug the audio cable from the computer, and check that you can hear the beep through the speakers. If you cannot, make sure that the sound is not muted, and that the sound drivers are properly installed. If you can hear it, plug the audio cable back into the computer audio output (NOT the microphone input), and make sure the g.TRIGbox has power; the light next to the power switch should flash momentarily if the battery levels are OK. You can also use a wall power source (see the g.TRIGbox manual for more information). The threshold is set correctly when the channel B LED is off at rest, and is on when a sound is played.

Video Threshold

To set the video threshold, first tape the optical sensor to the monitor in approximately the correct location, based on the information in the latencyTest.prm file for the window position and dimensions. To activate the optical trigger on the g.TRIGbox, drag a white window, such as a Notepad window, in the background under the sensor. Move the threshold knob for channel A until the LED for that channel is just on (i.e., turning it down just a little turns the trigger off). The sensor will be placed more accurately in the following step.

Starting the Software

Navigate to BCI2000/tools/BCI2000Certification, and double-click the BCI2000Certification.exe program. The BCI2000 program should start, with the output window in the location specified in the latencyTest.prm file. If there are any errors at startup, the BCI2000 error log will report them. If there are errors, correct them, exit out of the BCI2000Certification.exe program, and restart the program.

Setting up the Optical Sensor

Each application has a unique display configuration, where the visual target of interest is located in a specific position on the monitor. Generally, the optical sensor will not likely have to be moved far in between tasks due to the design of the parameter files. However, it is still necessary to ensure that the sensor is in the correct position for each task, and to be able to change the position if necessary. This section describes the process to find the correct location on the monitor for the sensor. To begin, the certification procedure should be started.

P3Speller

The P3Speller task has an group of letters arranged into rows and columns. The analysis uses the letter in the 3rd column and 3rd row, which will contain the letter X when the program is run. This location should be very close to that specified for the CursorTask, described above. Fortunately, the arrangement of the letters is shown before the test starts, which allows the sensor to be adjusted if necessary. All of the following default tasks are setup so that the optical sensor does not need to be moved from this position.

CursorTask

In the default configuration, the optical sensory does not need to be moved from the position used for the P3Speller task. For custom tests, the flashing object must either be placed under the sensor, or the sensor needs to be moved to the correct position.

StimulusPresentation

For the StimulusPresentation tasks, a single large icon appears in the center of the screen, which will be detected by the sensor. The default location of the sensor as defined for the CursorTask should be able to capture the icon on the screen. However, if the task begins and it appears that it is outside the icon location, move the sensor to the middle of the icon. Keep in mind that it may have to be relocated for following tasks.

Running the Tests

Once the optical sensor is setup and calibrated for a task, begin the testing process. To start the process, press the Start button in the BCI2000 operator window. At the end of each task, the program will quit automatically, and the next one will start automatically. For each task, press the Start button to begin.

Occasionally, the optical sensor may not be in the exact correct place for a given task.You should be able to see changes in on the video channel (channel 2 by default) in the window showing the recorded channels. If the signal is not changing when it should be (e.g., during the correct visual stimulus), you may try increasing the threshold to catch the stimulus, or you may need to place the sensor in the correct location. To do this, place the sensor in the better location, then quit the current BCI2000 test, and quit the BCI2000Certification program. The procedure will need to be restarted.

When the testing is complete, the BCI2000CertAnalysis program will automatically start. It will analyze the data that have been collected, and return the results in the results.txt file. In general, a Pass or Fail will be written next to a task, and each task component, if it passed or failed the test. For more information on interpreting results, see Sec. \ref{sec:results}.

BCI2000Certification: Additional Information

The previous section on Getting Started provided information to quickly setup and run the default tests. This section provides detailed information about each file used, and how to modify the files for your specific system and applications.

Overview of Important Files

There are several important files that are used in the BCI2000 Certification procedure. These files and their contents are described in this section.

BCI2000Certification.ini

The BCI2000Certification.ini file contains the information that defines each task configuration. It is located in the BCI2000/tools/BCI2000Certification/ folder. It specifies the parameter file, the SignalSource, SignalProcessing, and Application modules, and the analysis definitions for each task. It contains all of the default tests, although it can easily be expanded to include additional or customized task configurations.

Each task is defined by a set of case-insensitive , space-separated fields, as described below. A * indicates an optional field. The % character indicates a comment, and everything following that character is ignored.

• name The name of the task, which should be unique. This generally describes the task. It must not contain any spaces. This value determines the path to the saved data file, and the name of the file itself. For example, the name StimulusPresentation_512 would create a file at ./Data/StimulusPresentation_512001/StimulusPresentation_512S001R01.dat Example:
  • name StimulusPresentation_512

• parmThe BCI2000 *.prm file used for this task. It should be placed in the BCI2000/tools/BCI2000Certification/parms/ folder. Note that the CertificationMain.prm is included in all configurations by default, and does not need to be listed here. This file contains the information for this specific task configuration. See above for further information.
  • parm SimpleAV.prm

• source The SignalSource module to be used for this test. The g.tec g.USBamp system is used in all configurations by default. If the g.MOBIlab or g.MOBIlab+ are used, the SignalSource module should be changed to the appropriate executable. All BCI2000 executables are located in BCI2000/prog/. Examples:
  • 'source gUSBampSource.exe
  • source gMOBIlabSource.exe

• sigproc The SignalProcessing module that is used for this configuration. This is likely dependent on the application used as well. This program should be located in BCI2000/prog/. Example:
  • sigproc P3SignalProcessing.exe

• app The application for this configuration. This program should be located in BCI2000/prog/. Example:
  • app StimulusPresentation.exe

• *amp This is a single value that gives the channel that is used to compute the amplifier latency. Example:
  • amp 0

• *dAmp This is a single value that specifies a digital input channel that is used to compute the amplifier latency. Example:
  • dAmp 15

• *vid This field is followed by 3 values, that give the channel number that is recording the video output, and the state name and state value to use as a trigger for the comparison. See the example entry for more information. Example:
  • vid 1 StimulusCode 1

• *aud This field is followed by 3 values, that give the channel number that is recording the audio output, and the state name and state value to use as a trigger for the comparison. See the example entry for more information. Example:
  • aud 1 StimulusCode 1

• skip Entering skip will cause this task to not be run or analyzed. This is used to reduce the number of tasks that are run, which helps to repeat individual tasks that may have had problems in previous sessions.

• end This must come at the end of each task definition.

In addition to task-specific entries, there are several global entries that will apply to every task, unless explicitly overwritten in that task. This allows the user to quickly change settings for all tasks simultaneously, e.g., if tests will be run using a g.tec g.USBamp for one set of tests, and a g.tec g.MOBIlab for another. Global entries must be defined at the beginning of the BCI2000Certification.ini file outside of the task definitions. These entries are defined as:

• source The SourceModule to be used for all tests, unless explicitly overwritten by an individual task. Otherwise identical to the source definition in a task entry.
• export This entry does not use any other parameters on the line on which it is defined. If export is present in the BCI2000Certification.ini file, test results will be written to a comma-separated-value (CSV) text file that is located in the folder where data is saved for each task. For example, if the data folder is BCI2000/tools/BCI2000Certification/latencyData/, then the export file for the SimpleTarget task will be placed in the folder BCI2000/tools/BCI2000Certification/latencyData/SimpleTarget.

Here is a full example entry that includes two tasks.

source gUSBampSource
export

name StimulusPresentation_512
parm StimulusPresentation_512.prm
sigproc P3SignalProcessing
app StimulusPresentation
amp 0
dAmp 15
vid 1 StimulusCode 3
aud 2 StimulusCode 3
end

name CursorTask_1200
parm CursorTask_1200.prm
source gMOBIlab
sigproc ARSignalProcessing
app CursorTask
amp 0
dAmp 15
vid 1 TargetCode 1
end

The StimulusPresentation task uses the gUSBampSource source module, and records block-triggered digital outputs on channel 0, video output triggered off of stimulus code 3 on channel 1, and audio output triggered off of stimulus code 3 on channel 2. The SimpleTarget tasks overrides the global source entry, and uses its own source definition, specifying that a gMOBIlab should be used for acquisition instead of a gUSBamp. Finally, the export entry is set at the beginning, so test results for all files are output to a CSV file.

The BCI2000Certification.ini file contains many task definitions. Each entry is read by the BCI2000Certification.exe program, and is entered as a separate task to be run and then analyzed.

BCI2000Certification.cfg

The latencyTest.prm file is located in the BCI2000/tools/BCI2000Certification/ folder. It contains many default settings and definitions that determine how the results are interpreted, and should generally not be changed by the user. The timing definitions provide the absolute maximum latencies in ms for each step in the system chain, and include the Amp, ProcLat, VidOut, AudOut, VidSys, AudSys, and Jitter (see below for explanations). Timing definitions can include either one or two fields; the first field is mandatory, and is the mean value in ms, while the second field is optional, and is the standard deviation in ms.

• Amp The amplifier latency.
• ProcLat The processing latency.
• VidOut The video output latency.
• AudOut The audio output latency.
• VidSys The video system latency.
• AudSys The audio system latency.
• Jitter The system jitter. This is the difference, in ms, between the actual block duration and theoretical block duration, which is determined by the block size.
• Threshold Source Value This is the threshold defined for a specific SignalSource module. Individual amplifiers may have different input ranges, resulting in recording signals with different ranges of magnitude. The Source entry is a value in mV. For example, the threshold setting for the g.USBamp is Threshold gUSBampSource 12.5 .
• ResultOut This is the file that contains the testing results.
• DataDir The default data directory. It defaults to latencyData in the BCI2000/tools/BCI2000Certification/ folder.

These values should not generally be changed by the user, although they may be updated in future BCI2000 versions.

CertificationMain.prm

This parameter file contains some of the default task parameters common to every test, including the save location, monitor configuration, sampling rate, and visualization settings. Note that these parameters can be overwritten in the *.prm files for each individual test configuration.

BCI2000Certification.exe

This file controls the execution of each task. It parses the BCI2000Certification.ini and BCI2000Certification.cfg files to determine which files and tasks to run, and controls the CPU load monitor. When all tasks are complete, this program calls the BCI2000Analysis.exe program to handle the analysis of the collected data.

BCI2000CertAnalysis.exe

This program analyzes the data collected, and reports results to a data file. It uses the DataDir parameter in the BCI2000Certification.cfg file to determine where the data is located. Results are output to results.txt in the BCI2000/tools/BCI2000Certification/ folder.

Parameter Files

Each task should have it's own parameter file that contains the unique configuration and settings for that task. For example, there may be several configurations that use the g.USBamp, ARSignalProcessing, and CursorTask, each with its own parameter file. These files end in .prm, and are placed in the BCI2000/tools/BCI2000Certification/parms/ folder.

Interpreting Results

Results are recorded to the BCI2000/tools/BCI2000Certification/results.txt file. The results for each task, and each applicable latency tested, are reported here. If the entire task passed, then each test performed met the minimum timing requirements specified in the BCI2000Certification.cfg file. If one or more did not pass, then the specific test that did not pass the test has Fail written next to it.

What if a Task Did Not Pass?

TO BE ADDED.

Certification Protocol

This section describes how the testing protocol is run, the various components involved in the certification analysis, and how to interpret results.

Running the Tests

The certification protocol consists of running several BCI2000 applications in multiple configurations to determine if each application meets the minimum requirements for BCI2000, and to determine if individual configurations of an application meet the requirements. For example, the CursorFeedback task may be tested with several combinations of sampling rates, sample block sizes, and processed channels, only some of which may work with a given computer setup.

The testing set is run from a single batch file called LatencyAnalysis.bat. This file is located in the folder BCI2000/tools/BCI2000Certification/batch. This batch file executes additional batch files in this folder, each corresponding to a different application configuration. Each of these batch files starts the Operator module, automatically loading multiple parameter files used for a given configuration. There is a general-purpose parameter file called latencyTest.prm that all configurations use. This file configures the save location for all latency tests, as well as default window positions and sampling rates. A second parameter file is passed to the operator that contains the parameters for a unique application configuration. After starting the operator module, the batch file starts the SignalSource module, SignalProcessing module, and Application module. The loaded configuration is set automatically, and the user needs only to press the start button to start the analysis.

Software Templates

This describes how to implement the testing protocols for your own amplifier system and custom applications. This is useful for determining if your hardware setup and software is capable of maintaining an acceptable level of performance for real-time testing.

Amplifier Latency

The amplifier latency requires an output that can be recorded by the amplifier. In the case of the g.USBamp, a digital output line is used, although either analog or digital outputs could be used in a system.

In the SignalSource module code for your custom amp, find the Process function. Near the beginning of this function, before any data is acquired, set the output signal to 0, either a digital low or analog value of 0 V. This will be dependent on the particular amplifier and API used; for the g.USBamp, this function call looks like:
GT_SetDigitalOut ( m_hdev.at(0), (UCHAR)1, (UCHAR)0);

This sets the digital output 1 on device 0 to a value of 0.

At the end of the Process function, the output should be set to a high level. A similar function call will be used to above, only the value is 1 instead of 0; again, the function will be dependent on the system used, and whether analog or digital output is used. Here is the code for the g.USBamp:
GT_SetDigitalOut ( m_hdev.at(0), (UCHAR)1, (UCHAR)1);

This sets the digital output 1 on device 0 to a value of 1.

Visual and Audio Latency

Developing new video and optical latency tests does not necessarily require adding additional code to existing modules (beyond any customization already done).

Supported Hardware

A list of officially supported hardware configurations, and suggested minimum requirements is provided.

Supported and Tested Hardware

Amplifiers

• g.USBamp
• gMOBIlab (Serial RS232)
• gMOBIlab (Bluetooth)
• TDT Pentusa (RX5)

Minimum Requirements

Table \ref{tab:minreqs} shows the minimum requirements for running BCI2000. THESE WILL BE UPDATED LATER BASED ON OUR RESULTS!

Minimum System Requirements for BCI2000

CPU	1 GHz
RAM	512 MB (dependent on OS; 1 GB for Windows Vista)
Video Card	32 MB VRam; Hardware OpenGL Support
Sound Card
Monitor
OS	Windows 2000; Windows XP SP2 or Greater; Windows Vista

Voltage Divider & Amplifier Input

Parts List:

• 4 Male Mono Audio Connectors
• 6 12in Safety Connector Wires (to USB amplifier input), different colors
• 4 3in Wires
• Soldering Iron and Solder
• resistors for voltage dividers

This section describes how to assemble cables that connect the output of the g.TRIGbox to the amplifier input channels.

Strip the free ends of all 6 safety connector wires, about $\frac{1}{4}$ in. If you are not using voltage dividers, solder 4 of the wires directly to the center signal connection on the 4 mono audio connectors (Fig. \ref{fig:ampPlug1}). Cover the connection.

g.USBamp Amplifier Plug

Next, twist the two remaining safety connector wire ends together, and solder them together. Solder the 4 short wires to the ground connections on the mono plugs. Finally, solder the 4 ground wires to the two safety connector wires that were twisted together and soldered previously, as in Fig. \ref{fig:ampPlugs2}.

g.USBamp Amplifier Plugs

These plugs can plug directly into the g.TRIGbox outputs, and the safety connectors plug into the channels 1-4 inputs on the g.USBamp; the ground wires plug into the ground and reference on the g.USBamp.

Digital I/O Cable

Parts List:

• 3 Colored Wires
• 7-Pin Digital Connector from g.tec
• Soldering Iron and Solder
• Silicone or electrical tape for insulation
• 1 Female Mono Audio Plug

In order to access the digital I/O pins on the g.USBamp, a connector needs to be assembled. The 7-pin digital I/O connector should be ordered through g.TEC, the manufacturer of the g.USBamp.

At least three wires are needed for the circuit, which connect to the digital output 1 pin, the digital input 0 pin, and the ground pin (Fig. \ref{fig:digIO}).

g.USBamp Digital I/O Pins

To start, cut three 10 in wires, preferably with different colors to differentiate between the signal and ground wires. Cut back a small portion of the ground wire, and solder it to the center ground pin on the connector. Now, find the top of the connector by locating the small plastic notch, and locate pins 3 and 4 relative to the notch. Solder one wire to pin 3, and the remaining wire to pin 4. It may be helpful to insulate the wires from the casing using either a piece of black electrical tape, or an insulating gel, like silicone. If a gel is used, be sure to let it set for several hours or overnight. It is also probably a good idea to check the electrical connection with a multimeter prior to insulating.

g.USBamp Digital I/O Pins

Next, attach the rubber sleeve over the end of the part with the female threads, as shown in Fig. \ref{fig:digFinal} in the left side of the figure. Slide the smaller metal sleeve over the wires, then slide the larger rubber sleeve over the wires, as shown in Fig. \ref{fig:digFinal}.

For the next step, attach the two metallic pieces that surround the cables, shown laying to the sides in Fig. \ref{fig:digFinal}. One of the metal pieces has a small groove in it, which should be placed over the notch on the connector; the other metal piece fits on the opposite side of the connector. Push the small metal sleeve up to the side piece with the groove, and rotate the sleeve until the notch fits in the groove.

Place the end piece over the connector, with the red dot on top and aligned with the connector notch. Finally, slide the rubber sleeve over the connector, and screw the sleeve into the end piece.

g.USBamp Digital I/O Cable

The plug is assembled next. Solder the signal wire from Pin 3 (Digital Out 1) on the digital I/O connector to the signal connector on the female mono plug, and solder the ground wire to the outer ground connector on the plug. Figure \ref{fig:digplug} shows this; in this figure, the red wire is the signal wire, and the brown wire is the ground.

g.USBamp Digital Wire Plug