Page 1 of 1

Buffer Conditions for fixed Targets

Posted: 16 Jan 2009, 04:07
by aloplop

In the application I want to use (the modification of the Cursor Task Feedback),
two targets should be positioned on the edges of the screen,
but they should be fixed so there´s no random appearance.

In my case, the cursor moves just in the X direction, so the Buffer conditions
for the Normalizer must be introduced in the first column of the matrix.

However, I don´t know what boolean conditions would fit the best for
that kind of application in order to update the gain and offset values

What do you think ??


Normalizer ...

Posted: 20 Jan 2009, 15:03
by gschalk

I do not know what state variables you have for your modified task. However, what you want to do it seems like is to center the cursor in X, i.e., have the control signal be the mean of the signals during movements to the right and to the left target. Assuming TargetCode==1 is left target and TargetCode==2 is right target, and Feedback==1 during cursor movement, you would use



Posted: 21 Jan 2009, 04:18
by aloplop

Thanks for your response, but those conditions are the same than in the
Cursor Task, where the target appears randomly.

In the one I want to use, the cursor is centered in the screen and moves along
the X direction to the target on the left or the right.
The next week I´ll try the same conditions of the Cursor Task (what you have proposed) and using just (Feedback).

I´ll comment the results I obtain.

Thanks again,


Buffer conditions ...

Posted: 21 Jan 2009, 08:27
by gschalk

This is correct. It is the same, except in your task you need to adapt the first (X) control signal, whereas in the existing configuration we want to adapt the second (Y) control signal.

As you describe, in your application you want to center the cursor movement in X, i.e., you want to make the first control signal zero mean for the movement periods (Feedback==1). Thus, you could just use Feedback==1 if the target frequency is the same between left and right. If the target Frequency is different, e.g., 10 times to the left and 1 time to the right, just averaging the signal during all movement periods would effectively make it harder and harder to go in one direction (since you are averaging 10 left periods and only one right period). In such a case, you want to use the two conditions I mentioned. Then, you have two independent buffers, one for left target and one for right target, and the final calculated mean is in between both. Thus, this will also be correct in case target frequency is not equal.


Posted: 22 Jan 2009, 04:34
by aloplop

Gerwin, your response is very clarifying, so thank you very much once again.




Posted: 06 Feb 2009, 05:20
by aloplop
Hi again,

Finally, I performed some sessions with the fixed targets in the
application I developed to control a Wifibot and a video Camera.

Previously, I had made some tests in order to adjust the parameter
FeedbackDuration in CursorTask, using for the MaxFeedbackDuration
parameter the double of FeedbackDuration, and for the BufferLength of the
Normalizer, three times the value of FeedbackDuration.

At the end of those tests, we decided that the values should be 5s for FeedbackDuration,
10s and 15s for the other 2 parameters, in order to minimize errors, although there where some invalid or aborted trials.

The fact is that I tried to perform some sessions using this configuration and the Adaptation turned on in the Normalizer.
However, it cost me a lot to control the cursor. Sometimes it was almost impossible to move the cursor to one of the edges.

Furthermore, with those parameters I adapted the offset and the gain of the
Normalizer using the original CursorTask indicating the new positions for
the targets and configuring the classifier and Normalizer in order to
control the X axis, for at least 20 - 40 trials. Afterwards, I turned off the
Adaptation and tried to control the cursor in the Application for the Robot
with the two fixed targets.
In this case, I could control the cursor well, despite the fact that sometimes
it cost me a bit more to control the cursor to one edge than the other. This
aspect is translated in some aborted trials rather than "errors" in the
movement of the robot.

Using the second setting I performed 100 runs where I had to control the cursor to execute
some movements of the robot and the camera.
I supposed that an error was executing a wrong movement of the robot or the camera.

My results:

- 56/100 I completed the 29 "checkpoints" (not necessarily in 29 trials, sometimes a few more).
- In average, I have been able to control the cursor for 327 seconds
without obtaning an error.
- In average, I have completed 23/29 "checkpoints".

With Adaptation I just performed 20 runs because I obtained poorer results:

- In average I could only complete 8 "checkpoints" and 170 seconds without
an error.

So the question is:

- Why using adaptation I obtained poorer results??
Shouldn´t have I obtained better results??

If you have any doubts please, post a reply.



Adaptation ...

Posted: 06 Feb 2009, 06:57
by gschalk

Do you have UpdateTrigger set to an appropriate trial condition? This should be set to some indicator of a trial.

Also, it seems like your trials are much longer than in the original configuration. Thus, you should set the BufferDuration to a period that is longer than a trial.

In either case, this is most likely a configuration error. It's difficult to give you a better answer without the actual parameter file and without knowing about your task and how you encode the task-related events in states.


Posted: 06 Feb 2009, 07:05
by aloplop

for the Update Trigger I had:

Code: Select all

Filtering:Normalizer string UpdateTrigger= (Feedback==0) // expression to trigger offset/gain update when changing from 0 (use empty string 
About the duration, they last 10 seconds at max:

- FeedbackDuration: 5s
- MaxFeedbackDuration: 10s
- BufferLength in the Normalizer: 15s

This is because I made some tests using some FeedbackDurations and I obtained the best result for this configuration using a Matched Filter to my Mu-Rhythm at 11 Hz.

Maybe the system is not well configred at all. If you want more details I can send you an email.

Thanks again,


Normalizer ...

Posted: 06 Feb 2009, 07:13
by gschalk

From what you write, these settings seem to be similar to what's used in the CursorTask. You also write that the adaptation works fine in the CursorTask. Thus, the question is: what is different? One possible reason could be that your task does not encode the targets appropriately (or at all) in certain states (e.g., TargetCode), or the BufferConditions are not appropriately matched to whatever target encoding you have. I bet if you changed the BufferConditions to
[1] (for 1D) or [1 1] (for 2D), then it will work right away (although not quite as good as if you adapted on the targets). See

Continuous 1D Control without pre-defined Targets

in the Normalizer documentation.


Posted: 06 Feb 2009, 07:24
by aloplop

the unique thing that changes from the Cursor Task application is that the
targets are fixed in the X axis:

Code: Select all

Application:Targets:CursorFeedbackTask matrix Targets= 2 { pos%20x pos%20y pos%20z width%20x width%20y width%20z } 95 50 50 10 100 8 5 50 50 10 100 8 // target positions and widths in percentage coordinates
I changed the Buffer Conditions as indicated in the wiki:

Code: Select all

Filtering:Normalizer matrix BufferConditions= 2 1 (Feedback)&&(TargetCode==1) (Feedback)&&(TargetCode==2) // expressions corresponding to data buffers (columns correspond to output channels, multiple rows correspond to multiple buffers)
So, maybe for this kind of application should be better to use the
adaptation continuosly. However, for my application it seems that
the output values won´t appear with equal frequency:

- If the cursor hits the right target you select a movement.
- If the cursor hits the left taget you execute a movement.


Normalizer again ...

Posted: 06 Feb 2009, 09:13
by gschalk

What you describe seems OK. We recently fixed an issue with the Normalizer that produced incorrect adaptations in certain circumstances. Can you please update to the most recent version of BCI2000 and let us know whether this fixed your issue?



Posted: 06 Feb 2009, 09:55
by aloplop

maybe in the next week I´ll try the new version of the normalizer.

Thanks for all your interest.


Posted: 16 Feb 2009, 05:36
by aloplop
Hi again,

I updated the BCI2000 software to the latest version (revision 2280).

I used the conditions I suggested in the last posts but changing the
FeedbackDuration to 4 seconds, MaxFeedbackDuration = 8s
and BufferLength = 12 seconds in the normalizer.

I made some tests and the online operation was almost good. Maybe,
in the tests I had made, the problem was that I used 5 seconds (quite
a long duration). As I commented previously, with the Adaptation
turned on the movement was,sometimes, very hard. So, I had to adapt
the gain and the offset of the normalizer and then turn off this adaptation
to make the tests for my project.

I don´t know what are exactly the fixes you have done in the normalizer
but it seems now it works ok. In my opinion, there should be a commitment
between speed of the cursor and number of fails. Very long trials can be worse although
a person obtains less error %, because the mental effort
is higher. I hope this new version of the normalizer will help in the future



Adaptation ...

Posted: 16 Feb 2009, 20:50
by gschalk

This is a big reason why doing BCI research is pretty difficult.

From a signal processing perspective, results should get better with longer trials (since more data are averaged). However, as you point out, the subject may simply not be able to produce the appropriate signal for extended periods of time.