Forum for software developers to discuss BCI2000 software development
Posts: 17
Joined: 09 Jun 2011, 03:13


Post by Francesco » 11 Jul 2012, 10:55


Is it possible to make the porting of BCI2000 in Android systems such as tablets?
Can I use qt SDK?

Thank in advance,

Posts: 1115
Joined: 12 Feb 2003, 11:06

Re: Android

Post by mellinger » 11 Jul 2012, 11:28


we have never tried. In principle, it should be possible.

The BCI2000 core is programmed in a way that makes no assumptions about endianness, alignment, or struct layout, so it should basically work wherever it compiles.

Problems arise from source modules. Those that connect to amplifier hardware directly depend on SDKs that are generally not available for non-Windows OSs. Those that connect to amplifiers via network depend on third-party header files that do make assumptions about the binary layout of data in memory. These would need to be completely rewritten in order to work on non-x86 systems.


Posts: 58
Joined: 08 Jun 2009, 12:42

Re: Android

Post by griffin.milsap » 11 Jul 2012, 15:18

You probably could do it, but not without considerable effort. Emotiv and Neurosky both have mobile SDKs which gets past the embedded data acquisition barrier.

First off, you probably wouldn't want to keep Qt as the native interface. Although there is a Qt port to Android, the current BCI2000 GUI frontend isn't set up well for touch screens. I'd advise you program your own frontend using Android's native UI blocks based on liboperator.

Secondly, BCI2000 runs in several processes at the moment. One process for the Operator, one for the signal source, one for signal processing, and one for the application. Although it is theoretically possible to start up multiple APKs which then use some sort of Android Service IPC to communicate, there would be significant performance drawbacks to doing so. BCI2000 would have to be restructured such that the whole system can be run from one APK, and one context.

Third, depending on the experiment, BCI2000 has difficulty running on a desktop machine with a modern processor as it is. I'm not saying that the signal processing is inherently too processor intensive for an embedded device, but instead that BCI2000 is such a powerful toolbox that does a lot of tasks which could be pretty safely removed for an embedded platform. BCI2000 would need to be pretty heavily optimized to work well on an ARM. (Neon intrinsics and such)

Finally, Android runs Java. Java is the single largest barrier to doing any sort of realtime work on the system. Java is a managed language and usually picks the most inopportune times to perform garbage collection. These garbage collection runs can stall the entire operating system for short periods of time which would introduce large spikes in round-trip block time and make data analysis a nightmare. Using android for stimulus presentation is right out as well, due to the incredible audio/video latency issues the platform has.

BCI2000 has its place, and I don't believe mobile operating systems are a good fit. BCI2000 is an amazing toolbox for investigating signals, and prototyping systems. Once you find something that works, it makes sense to work on a purpose-built application for embedded devices or mass production.



Who is online

Users browsing this forum: No registered users and 5 guests