In the past years there has been an increased need and demand for real-time access to EEG data for purposes of quality control, parametrization, features extraction and online feedback. In this article, I will explore the concept of remote data access (RDA) and demonstrate how to access EEG data in real-time from our amplifiers.
Not long ago EEG analysis were left running overnight in an attempt to overcome the long and cumbersome processing time that computers offered. Nowadays, EEG data analyses take a few milliseconds, so researchers started to “listen” to the human brain and “change” cognitive states/functions during the experiment.
Taking advantage of the high temporal resolution provided by EEG and the possibility to have online access to the data, BCI and Neurofeedback research fields rapidly developed and grew. Brain Products always allowed researchers to have real-time access to data acquired with Brain Products amplifiers. We offer this possibility on two levels:
- Software Development Kits (SDK) – access on driver level our amplifiers without using a recording software
- Remote Data Access (RDA) – stream EEG data to other programs while it is being recorded
The SDK option is out of the scope of this article and you can find detailed information on how to access the USB drivers (amplifier dependent) in our website. In this article, I will describe how to use the RDA option and provide a detailed example of how to stream online data from BrainVision Recorder to an external program. But first, please allow me to give a general introduction to the RDA concept.
RDA is the term given to remotely access our recording software (BrainVision Recorder) and transfer data to other programs located on the local computer or on computers within the same network. In this process, the recording software acts as the server, and the program receiving the data acts as the client (e.g. BrainVision RecView). Data are transmitted via TCP/IP (Figure 1). It is important to highlight that it is possible to log up to ten clients to the server computer, whilst data are being saved at the server’s hard drive.
Figure 1: Schematic representation of the interaction between server and client computer.
Establishing Remote Data Access
In what follows, I will provide an example of how to establish a TCP/IP communication between a RDA Server Computer i.e. the Recorder computer and a RDA Client Computer where a Python script for online analysis is running. In this example the TCP/IP communication between two computers is established by using an Ethernet cable. It is important to highlight that if your computers are not equipped with Gigabit Ethernet, then you will need an Ethernet crossover cable.
Configuring the Server Computer
As stated above, the server computer refers to the computer where Recorder is running. Thus, the initial step is to enable the RDA option in Recorder. To do this, after opening Recorder, go to Configuration > Preferences …, select the Remote Data Access tab and tick the Enable Remote Data Access box (Figure 2).
Next, we need to set up the network interface in order be able to establish a TCP/IP communication between two computers. Since both computers are equipped with Gigabit Ethernet Technology, a simple Ethernet cable is used here in order to connect the server to the client computer.
Figure 2: RDA activation in BrainVision Recorder.
Once the connection is established, please go to Control Panel > Network and Sharing Center and open the Network Connection Details of the newly established Ethernet Connection. Here, you will find the IPv4 address of the server computer (Figure 3) which we will use latter when configuring the client computer.
A last step is to enable communication to the server’s RDA service. More specifically, we need to ensure that the port used by Recorder’s RDA server (i.e. port 51244) is not blocked by any of Windows security features and/or installed security programs (e.g. anti-virus, firewall, Windows Defender …). There are two possible ways to achieve this: either temporarily disabling all security programs or ensuring that the port used by Recorder’s RDA server is added to the exceptions list of your security program(s). While the former option is simpler and convenient as a temporary solution, the latter is more complex to achieve but nevertheless safer as a long term solution.
Figure 3: Network Connection Details: Server computer IP address highlighted in blue.
Configuring the Client Computer
The first task of the client program is to establish a connection to the server’s RDA service. This is done using standard socket programming which will not be covered here. Instead, I will describe how to configure one of our RDA clients’ scripts that are freely available in our website: RDA Client for Python (RDA.py).
Figure 4 shows an excerpt of the above mentioned Python script. Here, the red rectangle is highlighting the code line where the server address and port number needs to be defined. From the previous section (Figure 3) the server address (where Recorder is running) was identified as being 169.254.7.107. Please be aware that the server address might differ every time a new connection is established and so the code line needs to be modified accordingly.
Figure 4: Excerpt of the RDA Client for Python (RDA.py). The red rectangle identifies the code line where to add the server IP address and port.
RDA Client for Python output
In the last two sections, it was described how to configure the server and the client computer. The next step would be to start Recorder in Monitoring mode and run the RDA.py at the client computer (please ensure that you have Python software installed at the client computer). Once the connection is established, the client then waits for data or messages to be sent from the server. Further details about the contents and structure of the transmitted data block can be found in the Recorder User Manual, more specifically in the Remote Data Access chapter.
Figure 5 shows the console output at the client computer when running the RDA Client for Python. In this specific example, and among various output messages, the average power of all channels is calculated over a time period of one second and printed into the console.
Figure 5: Windows command line output when running the RDA Client for Python.
Drawbacks and Limitations of RDA
TCP/IP communication is well known to be a reliable block-based transmission protocol. Thus, we have adopted it in order to allow researchers to remotely access their data in real-time. But any decision comes with a cost, and we are aware that when accessing the data remotely, a delay in the real-time transmission should be expected.
Taking into account the overall EEG signal pipeline (i.e. amplifier hardware filters → A/D converter → USB communication → Windows OS → RDA server (Recorder) → Ethernet Connection (TCP/IP) → RDA Client), average delay times for RDA are in the 50 – 100 ms range. This delay strongly depends on the RDA signal pipeline, heavy processing time, and usage of TCP/IP connection by another application. Even though in most applications the delay time is within the acceptable range, it is indeed one of the RDA limitations.
That said, RDA offers the most convenient, but not the fastest route to access data in real-time. Thus, and if you work with real-time critical applications, please keep in mind that there is always the possibility to access directly the USB drivers of our amplifiers without using a recording software (please see above, SDK) and therefore greatly decrease the delay time.
Accessing data in real-time from Brain Products amplifiers is possible either by RDA or SDK. The existing RDA option gives you full flexibility to program your online application in your favourite and preferred scripting language. Furthermore, and in order to ease the process of implementing and programming your online analysis programs, Brain Products offers free access to sample codes of RDA clients (unsupported) in the most common programing languages (Matlab, C#, Python, C++). These sample codes could be used as a starting point/programming template for your own application.