Q&A with BrainFlow Creator Andrey Parfenov

Andrey Parfenov is a Russian born software engineer and the creator of BrainFlow. He has previously worked at Intel, Nvidia, and as a researcher at the University of Innsbruck. When he’s not writing code, Andrey enjoys basketball and musicals. 

To learn more about BrainFlow visit:

When did you first get interested in EEG & neurotechnology?

My interest in neurotech and BCI came out of a habit I have of buying strange hardware devices as a way to learn new skills. Four years ago I was interested in FPGAs and bought a Terasic DE-1 SoC and a few other devices as a way to learn more about integrated circuits. Once I buy a device, I find myself more motivated to put it to use. Through this particular tool, I learned things like how to implement neural networks on FPGAs from scratch without using higher level pre-built frameworks

I don’t think there was a specific thing that made me interested in BCI, it’s always been well-known among other engineers I work with and something that I’ve been aware of. In summer 2018, I decided that I needed a new personal project and that brain-computer interfaces would be a good area to focus on. I knew that working with BCI’s would push me to learn more about signal processing and machine learning, and I was interested to see for myself how BCIs could be applied in game development.

I started googling “low cost BCI” and came across Emotiv, Neurosky, and OpenBCI. I believe that having to pay extra for access to raw data is unacceptable, and at the time, it seemed that Neurosky was not built for scientists or software engineers. I liked that OpenBCI allowed access to the raw data for free and made it easy to customize the hardware itself.

I am also a fan of open-source projects, so I ordered a Cyton and got started tinkering with it. 

What is BrainFlow?

BrainFlow is a library intended to obtain, parse and analyze EEG, EMG, ECG and other kinds of data from biosensors.

Brainflow provides a uniform data acquisition API for all supported boards. This means that you can switch among supported biosensing hardware without any changes in code and applications on top of BrainFlow are board agnostic. Also, there is a powerful API to perform signal processing which you can use even without a BCI headset. Both of these two APIs are structured the same across all software bindings.

BrainFlow currently supports bindings for the following languages:

• Python
• Java
• R
• C++
• C# (Windows only)

Why do you think BrainFlow will be helpful to the Open Source community?

One idea I’ve always kept in mind while working on BrainFlow is “write once, run everywhere.” 

I wanted to make that possible for people working with biosensing tools like OpenBCI. All the core modules of BrainFlow are written in C++ and exposes plain C interface to bindings through dynamic libraries loaded in runtime. All general purpose and scientific programming languages allow calling plain C functions, so by starting with a plain C interface, we don’t limit users to any specific programming language and we maximize code reusability. At the same time, BrainFlow’s developers are able to use all modern C++ features and object-oriented paradigm.

Similarly, BrainFlow is designed to be hardware agnostic. Most BCI vendors have their own SDK which is designed to only work with their own hardware. This makes it very difficult for application developers to add support for other hardware without having to write new code from scratch. The way BrainFlow handles different biosensing hardware is specifically designed to make it easy for application developers to switch to any supported device without needing to rewrite the code. 

One of the other helpful features is the built-in emulator. BrainFlow includes a powerful CI/CD system which runs integrations tests for each commit automatically. This emulator is able to test the countless combinations of different OS environments and biosensing hardware. As support for more boards, bindings, and environments is added, this emulator function will be invaluable for users who want to maintain their applications. 

BCI and neurotech are still in their early stages, so everything about BrainFlow is written with the future in mind. The process for adding support for new hardware is simple, and I hope other manufacturers will see the value in BrainFlow’s flexible foundation. By following the instructions for integrating a new board into BrainFlow, developers will get SDKs for Python, Java, C#, R and C++ without having to write code for each language individually. 

Why did you decide to build BrainFlow?

I began soon after I started working with the OpenBCI Cyton. It did take me a few tries to get my device successfully delivered to me in Russia, although that’s a story for another time. Once I received my device, one of the first things I started working with was the OpenBCI_Python software library. I struggled with even the basic examples and overall, I was extremely disappointed with the experience of working with that library as a first time user. 

I thought this may have been an isolated issue with OpenBCI Python, but as I looked through github at the SDKs for other languages, I noticed a theme. They each had slightly different ways of handling the exact same thing…as if each had been written independently at different times. This lack of consistency is something I’ve seen a lot when jumping into other projects that have slowly expanded their scope over time. I understood how it could happen, and knew that it was going to make it harder for OpenBCI to maintain and improve the SDKs, and for anyone like myself who was looking to develop on top of them. OpenBCI has created one of the more accessible hardware platforms for creating BCIs and I saw an opportunity for me to improve the situation on the software side. 

As a programmer, and now as a user of OpenBCI, I became inspired to make something that would be easier for developers to maintain and build on top of. The challenge was similar to something I had faced while working at Nvidia where I was developing C++ libraries and Python bindings to collect performance metrics from video games. I thought that a similar process could be used with OpenBCI to collect physiological data from the body. I decided to go big and to tackle many languages at once, mostly because I knew how to do it, and I knew it would help other BCI developers.

I decided to get started on creating my own open-source software library that would make it simple to work with multiple boards in multiple languages. I would contact OpenBCI when it was ready and thought maybe they would find it useful and share it with their users. 

What was the biggest challenge while developing BrainFlow?

The biggest challenge was working with bluetooth and BLE. All OpenBCI boards use different communication protocols and there is nothing common between them, so it decreases possible code reuse. The biggest challenge was to add support for Ganglion because BLE protocol is handled very differently across OSes and some of them have limited support for it. Fortunately the source code for common BLED dongle is open-source and allows you to work as if they were serial ports. After fixing some issues with this code, I was able to add support for Ganglion and BLE. 

The first version of BrainFlow took two months of working during my free time. I reached out to OpenBCI towards the end of 2018 and the first response was “Wow! Great job!” which, as I understand, is American for “we’re not interested.” I didn’t hear anything back for a month or two after that so I decided to continue to build it up. I wanted to add an application to prove how it could be used. I made a P300 speller application as a proof-of-concept and it worked! It was just a proof-of-concept, and there were lots of parts I could improve, but at the time it was a step forward for demonstrating how BrainFlow could make things easier for people working with EEG data. 

I sent two more emails to OpenBCI about BrainFlow, got a few more “great jobs” and then eventually around April 2019 I started having more serious discussions with people like Conor [Russomanno] and Daniel [Lasry] about what I had built. This eventually led to me establishing a working relationship with OpenBCI and being hired as a contractor in May. 

Were you surprised to have ended up working with OpenBCI directly?

Yes. I thought maybe you would send me a few boards for free. I’m glad my persistence paid off. I feel like the opportunity to get involved in the BCI field in a meaningful way is like starting work on deep learning 15 years ago. 

What does the future look like for BrainFlow?

Originally, BrainFlow was only for the Cyton board and I thought that maybe I would expand it to Ganglion and that’s it. Now that I’ve been able to spend more time on it, the goal is to add support for as many different bioamplifier boards as possible, not just OpenBCI manufactured ones. 

My next steps for BrainFlow would be: (1) develop new applications on top of it that demonstrate specific use cases, (2) integrate BrainFlow into other applications such as OpenVIBE, MNE based applications, and the OpenBCI GUI. I intend to spend some time tackling each of these myself, but I’m hoping that other members of the neurotech community will see the value in BrainFlow and want to address these points on their own. 

How would you like to see open-source brain-computer interfaces used in the future?

I believe the primary goal of OpenBCI & all other companies in the neurotech field should be enabling real life applications. I believe gaming and AR/VR is one area where biosensing and BCIs will be applied soon and I’m glad OpenBCI is starting to focus on that area with its latest project. I want to see more open-source software applications that address applications other than research. Invasive interfaces aren’t suitable for mass adoption because the need for surgery makes it either too expensive, or too risky. I think the widespread applications of this technology will be non-invasive, and hopefully, they will be publicly available. 

I see the first breakthrough coming from gaming. I expect to see EMG, EEG, or other biosignals being used not only as a method of issuing commands, but also as a way of changing elements of the game itself (colors, music, weather, etc…).