Page 1 of 1

AppConnector Signal extraction

Posted: 27 Mar 2012, 06:00
by vladi

I would like to know if there is a possibility to get the signal from the source module using the AppConnector.


Re: AppConnector Signal extraction

Posted: 29 Mar 2012, 01:24
by boulay
If you use a signal processing module that is a simple pass-through then the signal reaching the app connector module should be the same as what leaves the source. If you require the signal processing module to do something, then you can still pass through the unprocessed data by concatenating them to the processed data. i.e. if your source has 16 channels, then your signal processing module will have 16 channels for input and 32 channels for output, where the first 16 of those output channels are processed and the last 16 are unprocessed copies of the input.

Re: AppConnector Signal extraction

Posted: 29 Mar 2012, 04:54
by vladi
Thank you very much for you answer. For the signal processing module I use the ARSignalProcessing and the signal I get via the AppConnector is the output of the normilizer if I understood this right. So before the signal is send out via AppConnector it undergo the SpatialFilter the ARFilter and so on. So my question is how I can applie this filters just to a set of the channels and let the other channels unfiltered and send both out via AppConnector.


Re: AppConnector Signal extraction

Posted: 29 Mar 2012, 07:31
by mellinger
The AppConnector protocol sends each channel and sample as a separate message, e.g., "Signal(1,2) 23.45". You will probably run into timing problems when using the AppConnector protocol to send raw data.

If you still want to try: You can configure your own signal processing module, such that it gives you both its input signal, and its normalizer output in the control signal sent to the application module.
BCI2000 provides template filters for creating parallel and serial combinations of filters, which can be combined to achieve what you want: BCI2000/src/shared/modules/FilterCombination.h contains definitions for ParallelCombination<Filter1, Filter2> and LinearCombination<Filter1, Filter2>.

In the ARSignalProcessing module's PipeDefinition.cpp, add #includes for "FilterCombination.h" and "IdentityFilter.h".

Then, re-create the existing filter chain as a structure of nested LinearCombinations:
struct LC1 : public LinearCombination<SpatialFilter, ARFilter> {};
struct LC2 : public LinearCombination<LC1, LinearClassifier> {};
struct LC3 : public LinearCombination<LC2, LowPassFilter> {};
struct LC4 : public LinearCombination<LC3, Normalizer> {};

Now, create a parallel combination of the IdentityFilter, and LC4:
struct PC : public ParallelCombination<IdentityFilter, LC4> {};

Finally, remove all the "Filter()" statements, and replace them with a single one:
Filter( PC, 2 );

The output of this modified signal processing module will contain the source signal in its first channels, and the normalizer output in its last channels. The normalizer output will be padded with zeros to match the number of samples in the source signal.


Re: AppConnector Signal extraction

Posted: 29 Mar 2012, 09:15
by vladi
Thank you for your replay. Just to get it right this approach is useful if I would like to get the filtered signal of one channel and the raw signal of the same channel via AppConnector. But what I would like to do is lets say I have 4 channels the first three channels should be filtered and the 4rt channel not be filtered and passed with the AppConnector. So I could just exclude the 4rt channel with a if statement within each method in signal processing module like this:

for( int ch = 0; ch < Input.Channels(); ++ch )
if( !mDoFilter[ch] )
for( int sample = 0; sample < Input.Elements(); ++sample )
Output( ch, sample ) = Input( ch, sample );

I think the problem is that the length of the vektor of the first three channels compared to the 4rt channel are different in the end. But I would use the first three channels as a control signal thus as a input for the application module and the 4rt I would like to read out for other purpuses. So the problem with you advice is that the control signal would be padded with zeros and then passed to the application module and this is what I would like to omit.