App Connector Protocol Problem

[cdocon]

Hi Everyone,

I am attempting to read the state vector and control signal from BCI2000 using the app connector example shown in http_nospam_www.bci2000.org/wiki/index. ... _Connector. While I can connect to BCI2000 and receive data, the protocol is often clipping newline characters, or transmitting blank lines (or clipping the entire line?), so the result in the standard output is something similar to:

Code: Select all

Signal(1,0) 16.845
Signal(1,1) 48.6541
Signal(1,2) 56.3917
Signal(1,3) 76.9754
Signal(1,4) 94.6816
Signal(1,5) 98.301


Signal(1,24) -21.7643Signal(2,4) 92.4908Signal(2,18) -96.7638Signal(2,25) -2.38242Running 1
SourceTime 54469
StimulusTime 38734
Signal(0,0) 95.0697
Signal(0,1) 85.3304
Signal(0,2) 76.4927

The program is running on an different machine (Ubuntu 14.04) to that of BCI2000 (Windows 7), however they are both on the same LAN so I can't see packet loss being the culprit of this many errors. I was hoping someone could enlighten me as to why this is happening and how to stop it as it makes parsing the data difficult.

At the moment I am just attempting to receive raw signal data, so I am using SignalGenerator as the source, and DummySignalProcessing and DummyApplication for the Signal Processing and Application modules respectively.

Thanks.

[boulay]

I don't know what the problem is but I might be able to suggest a couple things to help you isolate it. I know the following is not a solution to your problem.

First, try running the app receiver on the Windows BCI2000 computer.

If that still doesn't work then try using a SignalProcessing module that returns a realistic number of control signals.
(Most applications only need one control signal value per block per feedback degree of freedom).

If you reduce it down to a few signals per block and use a single computer yet you still see the same problem then I would guess that it is not a problem with the amount of data you're trying to push through the network, rather there's a problem with the transmitted data itself.

I notice in your example that most of the data segments with failed newlines tend to be 2 characters longer than the segments without that problem. However, this is not true for the Signal(2, 4) segment so this is unlikely to be related to the problem (I was thinking the max segment length - if such a thing exists - was being exceeded and not allowing the newline terminator). In your post you said the output is "something similar to" what you provided, so I don't know if this is a contrived example or a clipped example. If it's the former, then please check the length of your data segments.

[cdocon]

Hi, thanks for your help. I attempted what you suggested and got the following results:

1. Running the application on the same Windows machine seemed to largely fix the problem, aside from the "Running 1" element occasionally being appended to the previous line.
2. Reducing the number of control signals to three channels with one element per channel per block and that completely fixed the issue (Linux).
3. The example I posted was copied from the standard output from a run so unfortunately the data segment length is unlikely to be the cause.

From this it sounds like it may be an issue with the amount of data being pushed through? If so this is unfortunate as I was hoping to use BCI2000 to acquire the signals and apply some preprocessing methods (such as spatial filter and FFT) before having feature extraction handled by a separate application, unless there is another/better way to acheive this that I have missed?

[boulay]

Here are a couple things to try:

(1) Go around whatever network hardware you are using. Do a straight ethernet-to-ethernet connection between the two computers. If your network cards are really old then you may need a crossover cable, but it would probably be better to get newer network cards.

(2) Make a BCI2000 module that runs on your linux machine. I've never done this but others have. The modules do not all have to be on the same machine. The communication protocol between modules is TCP/IP so you will not lose packets.

Good luck, and let us know what your solution is.

[cdocon]

Option 2 sounds like a good idea, I think I'll give that a shot. Thanks!