bci2000.org BBS

Question: Should online control features be selected based on task-specific spectral amplitude/power changes with or without adaptive normalization? If adaptive is best, then how can we use OfflineAnalysis to help us select the best feature?

Read the following if you require more details.

Using the OfflineAnalysis tool I'm getting nice 1/f spectra during imagery and similar spectra during rest with the exception of a nice peak around 14Hz. This also yields great rsq values around that frequency. See the attached figure. {5:C3, 6:Cz, 10: P3, 11: Pz}. I did not use any spatial filter. Based on this assessment I would use C3 @ 14Hz as my control signal.

I tried to simulate this result by using the bci2000chain tool using only . I tried to match the AR parameters to those used by OfflineAnalysis as best as I could. While I can't match the SampleBlockSize after the fact, I can match the WindowLength. I don't know which WindowFunction OfflineAnalysis' mem uses, if any. In the attached figure the red line is the rsq value (right y-axis). Everything else is labeled. The results are pretty similar. Of course no one uses these raw amplitude values for control. Assuming no spatial filter and only C3 @ 14Hz is our control feature.

How should I normalize this feature for control?

A simple, non-adaptive, way to normalize would be to take the median value of C3 @ 14Hz as the offset and then scale by 1/variance. In my experience, spectral amplitude is not normally distributed so it seems like the cursor will not have equal speed on either side of the midline. I find that brain signals can be made a little more normal by taking the power in db (10*log10(amplitude^2)) but currently BCI2000 does not offer this option.

We can also use an adaptive normalizer http://www.bci2000.org/wiki/index.php/U ... Normalizer. This way the offset and gain are updated every trial based on some previous data. The problem with this is that the result of adaptive normalization isn't really the same as the result using OfflineAnalysis.
I repeated the bci2000 chain analysis using . The LinearClassifier simply turns every channel x frequency into an output channel and the normalizer is set to 'adaptive' using 3 s of baseline data. The results are quite different. Based on this Cz at 14Hz is now better and C3's rsq peaks at 8Hz.

If I had hours and hours of data instead of the 40 trials here, would the results converge?

Should cursor speed be 0 at the beginning of a trial (i.e., normalized to baseline)? Should we assume that there is some drift in the control signal that the subject will never have voluntary control over and therefore normalize the cursor speed to some previous amount of data? Or should the cursor speed always be some direct transformation of the current amplitude (or power) with the expectation that the subject will eventually learn to return the signal amplitude to baseline between trials?

Does the answer change if the goal is to induce plasticity vs to provide useful control?

Thank you for any insight.

Normally a spatial filter is helpful and you might consider evaluating one (e.g., Common average or surface Laplacian).

The bias due to the skewed distribution of signal amplitude values can be reduced by a log transform as you suggest. See the expression filter (http://72.249.19.64/wiki/index.php/User ... ion_Syntax )
for a possible implementation of this.

Using 3 sec for the adaptive normalizer is way too short! When you say that you are using a "baseline" do you mean that you are using the interval before the trial? Normally I have used values during the trial for the normalizer. This requires several multiples of the trial length (e.g., 8 x or 24 sec for 3 sec trials).

Dennis McFarland

I use a Laplacian for my experiments but the OfflineAnalysis tool doesn't support that by default so I didn't use it for this comparison.

Thanks for the tip about the ExpressionFilter. I'll give that a try.

I know that you typically use 24 s of previous trials' feedback data for the normalizer buffer. Yes, I am using the 3 s preceding the current trial's StartCue in the normalizer. (My current lab typically uses a 3-5 s baseline period though here they scale by the average baseline amplitude, not by the variance.) It's not clear to me why 24 s is better than 3 s, or 0 s.

If 24 s is indeed advantageous, and the OfflineAnalysis tool's results don't reflect adaptive normalization, then should we upgrade the tool so that it supports adaptive normalization?

One obvious difference between using a longer buffer and using a buffer that only uses the pre-trial period is that with a longer buffer the feedback period will probably begin with a non-zero speed whereas the pre-trial buffer should start the trial with a speed near 0. I assumed that the latter would give the subject a greater perception of control but this might not be true, especially considering how unstable the gain is when calculated from the variance of such a short period.

What about the difference between using adaptive normalization (of any buffer length) or using no adaptive normalization at all? In the former, the subject is training to control their SMR amplitude up and down around some wandering mean. In the latter, they are training the absolute value of the SMR amplitude. Which one would lead to better control? Since you use the former method then I assume you think that the former method is better for control. What about for inducing plasticity? Maybe this question can be rephrased as: "Is the SMR amplitude or its slope a better biological marker?"

Through some discussion I think this issue has been distilled down to a couple separate questions.

For general BCI researchers:
If your goal is to provide the best control, should adaptive normalization be used?
If your goal is to induce some cortical change as a result of BCI training, should adaptive normalization be used?

For the BCI2000 community:
If OfflineAnalysis is used to select feedback control features, then should OfflineAnalysis have the option of doing adaptive normalization in its analysis?

Using the same 40 trials as I used above, I processed the data using the bci2000 filter chain with the following conditions:
fs 2400 Hz,
spatial filter LLP of C3,
AR: {WindowLength: 0.3329s, Detrend: mean, WindowFunction: Rectangular, FirstBinCenter: 0Hz, LastBinCenter: 40Hz, BinWidth: 2Hz, OutputType: SpectralAmplitude, ModelOrder:42, EvaluationsPerBin:10}
LinearClassifier: input -> output
LPFilter: 0.5 s,
ExpressionFilter: 20*log10(Signal)
Normalizer: Offsets: 0, Gains: 1.
Normalizer adaptation and Buffer were changed for each plot (see plot titles).
As you can see how we choose a control feature is affected by whether or not we use a normalizer as well as the normalization parameters. Using a 24s buffer filled only with data from the feedback period leads to rsq values so low we can't see them at this scale. I realize that these data are anecdotal and the best method is likely to vary across data sets. I am not trying to say one method is better than the other, simply that they are different and that OfflineAnalysis uses the first method while online we typically use one of the others.

In the context where you have repeated trials, each of limited duration, and each with a known set of targets, the Normalizer's adaptive normalization seems to work very well. You can use a limited period (3s) from *each* trial but you'll need to make the buffer much larger so that it is averaging from the last n trials of each class. For the wider context of freely controlling an effector (cursor, arm, etc), where there is no ground-truth and no balance (you might actually want to work only on the right-hand side of the screen for half an hour) then I think the jury's still out. In fact the jury probably hasn't even turned up for duty yet. I do not know what the best policy would be.

As regards giving the OfflineAnalysis tool an overhaul I think that's a great idea. There's often been a gulf between online signal-processing and one's attempts to recreate something similar enough offline (and how similar is "similar enough"?). BCI2000Chain is a relatively new tool (or at least, a relatively new interface to the tools) which addresses that problem, as you've discovered. Any future version of the OfflineAnalysis tool should at least be based on the same principle—or perhaps based directly on BCI2000Chain itself. The trick would be to wrap it up in a simple enough GUI (which would nonetheless still provide complete freedom in "advanced" mode, of course) because currently BCI2000Chain is pitched only at people who can write their own analysis code.