questions about State information

[phammon]

My name is Paul Hammon and I am working with the Swartz Center for
Computational Neuroscience to modify one of their BCI2000 experimental
setups. I have been having problems with the State information. I
tried to add a couple of State variables, but seem to have broken
things so that none of the original state variables or the variables I
added are output. There are various other (apparently built-in)
states that are written, but none of the ones I added or the other
custom states that were available before I made my modifications. The
code that I am using to define and update the State information is
copied below. Note that all this code is in Task.cpp:

// in Task()
BEGIN_STATE_DEFINITIONS
"StarTime 16 17528 0 0",
"Star 8 0 0 0",
"TaskChange 8 0 0 0",
"TaskStateTime 16 17528 0 0",
END_STATE_DEFINITIONS

// in Process()
State( "StarTime" ) = BCITIME::GetBCItime_ms();
State( "TaskStateTime" ) = BCITIME::GetBCItime_ms();
State( "TaskChange" ) = tsk_chng;
State( "Star" ) = star;

The only other place I can find reference to the State information is
the parameter setting which reads:

System int StateVectorLength= 7 16 1 30 // length of the state vector in bytes

Trying to change this setting seems to crash the program rather consistently.

Also note that I am able to access the new State information within
the program and print out the changes to state for debugging. Using
this approach, I can get access to the State vector and everything
appears to be working:

int chng = State("TaskChange");
int star1 = State( "Star" );
double start1 = State( "StarTime" );
double taskt1 = State( "TaskStateTime" );

sprintf(memotext, "change=%d, startime=%.2f, star=%d,
taskstatetime=%f, step=%d, time=%d",
chng, start1, star1, taskt1, acqCounter, acquire1->getTime());

The States that are available upon converting the .dat file to a
Matlab file are:

Pitch
StimulusTime
Feedback
Running
SourceTime
Recording

If you have any experience working with the State variable or have any suggestions, please let me know.

[gschalk]

Paul,

There are a number of interesting clues in your description. First, you state that you could successfully access the state information during online operation. This suggests that the states are correctly requested and initialized at least within the UserApplication module. To verify that the states also correctly make it to the Operator module, I would select View->States in the Operator module. You should see your requested states there as well.

Second, you state that somehow these states do not make it into the datafile. The first reason that I could think of is that you are using a combination of modules with incompatible protocol communication. (A few months ago, we completely changed the underlying framework. While the communication protocol should not have changed, we never evaluated whether we could combine modules compiled with the old framework with modules that were compiled with the new framework.) You could test this by downloading the most recent version of BCI2000 from the CVS server. When you compile this version (make clean && make all) everything should work. If you then compile your custom UserApp with the new codebase, it should still work.

Upon closer inspection, I found a third, and possibly crucial, clue. You report that one of the states that successfully shows up in the converted Matlab file is 'Pitch.' Now this is interesting, because your code does not request 'Pitch.' Furthermore, the only code that I know does request this state is the 'LittleDemoApp' demo User Application (verified using grep -i -d "Pitch" *.cpp). Since you can't be using two UserApps at the same time, this makes me believe that the data files that you are looking at have not been recorded with the system that was running online, but are possibly data recorded previously. Please double check your paths/file names in Storage and make sure the data file has the correct date/time.

In summary, I suggest to first check that you make sure you are looking at the data files that were actually created by the online program. These data should not contain the Pitch state. If they do not, but still do not contain 'your' states, download the most recent code of the whole project, compile your UserApp with the most recent codebase, and run it with the other most recent modules. This should definitely work.

Finally, it is also possible that you made incompatible changes to the framework itself. To ensure consistency with newer versions, the only code that you should change (in the UserApp) is in Task.cpp. Please consult the Software Design Document for more information.

I hope this helps. Please let me know as you find out more.

Gerv

[gschalk]

Hey Paul,

After consulting with Juergen, our lead software engineer, here are two more pieces of information:

If you used LittleDemoApp as a basis for your task, you might have linked the 'old' Task.cpp into the project (in addition to the new one). In this case, the linker might create an undefined mixture of both. Do you get any linker warnings?

>> (A few months ago, we completely changed the underlying framework. While the
>> communication protocol should not have changed, we never evaluated whether we could
>> combine modules compiled with the old framework with modules that were compiled with
>> the new framework.)

Juergen points out that he had actually tested an application that was compiled with the old framework in conjunction with other modules compiled with the new framework. Thus, this should not be the problem either.

Gerv

[phammon]

Hi Gerv,

I got a chance to look at the BCI2000 application again today. I did not find any linker errors, and View->State yielded the states that I expected to see, with the additions of Running, SourceTime, and Recording. So this line of investigation did not yield any news.

(One thing worth mentioning is that I use the BCI2000toASCII tool to convert the BCI2000 files to Matlab format. I decide whether or not the proper states have been recorded by looking at the Export States window.)

Then I went back to previous versions of the application and tried running them. As a consequence of using old parameter files, I ended up saving the output .dat files in a different directory. This is when I noticed something odd: I got different states being visible to BCI2000toASCII depending on which directory I saved to. So, I made a new directory and used my version of the code with the random number generator, and suddenly the new states I added were visible and Pitch was gone.

I found this really hard to believe, so using the same parameter file, I saved one run in the original output directory. Then I changed just the SubjectName back to the name of the new directory, ran the application, and saved the output (in the new directory). Amazingly, the output file in the new directory had the proper states, and the output file in the old directory had incorrect states. I have not yet tested with the actualy EEG data source, but expect to get similar results.

I do not understand what could possibly be causing this effect other than some quirk in the way that param files or BCI2000toASCII change things. Any thoughts?

Thanks,
Paul

[gschalk]

Paul,

You should not see different states depending on the data directory. Because this seems what happens to you, there are two possibilities:

1) You are using the most recent version of BCI2000toASCII, but you select more than one file and the files have different states. It will show the states of the first file only, so if this file has other states than the ones of the subsequent files, there might be a problem.

2) You are using an older version of BCI2000toASCII. I do recall that earlier versions might show the states of the first run in the directory regardless of what files you selected.

The most recent version is V3.8 and does not have this error. I checked.

Gerv

[mellinger]

Paul,

the header of a BCI2000 .dat file is human readable.

When observing "strange" things, use a text editor (or "more myfile.dat" from the command line) to tell what states and parameters are contained in a given dat file.

Juergen