bci2000.org BBS

Hello,

I'm running a few sample .dat recordings through the mu rhythm classifier using file playback. I can only get access to an EEG once every two weeks and I don't have MatLAB, just to clarify. I'm also a beginner at this.

So anyway, I've done the inital mu session, run through an offline analysis and got some channels + frequencies with high R^2 values. I'm having issue with the spacial filtering matrix however. I can bring up the full matrix by pressing the 'edit matrix' button, but it's already a 4x4 matrix, and the cells are filled: 1 if x=y, 0 if x!=y (x being column no., y being row no.) If needs be, I'll post a screenshot.

The tutorial says to right click on the first cell and choose Edit labels. I don't have that option in the context menu, I only have:

Edit Submatrix (greyed out)
Convert to submatrix
Replace with single cell

What is it I've got wrong? I'm quite sure I'm on the latest binaries.

The other issue is when I'm just trying out the CursorTask batch file with Playback running my own .dat file. I keep getting a this error:

CursorFeedbackTask::Initialize: Parameter "PreRunDuration" was accessed during initialization or processing, but not checked for consistency during preflight phase.

I've tried chaning the PreRunDuration value but it doesn't seem to make a difference, could it come from a conflict of when the playback file starts and the application starts?

Would you mind sharing what you are trying to do with the file playback? I ask only because (my impression is that) the playback module is not meant to be useful for beginners. There are lots of small details to get right if you want file playback to be useful. Could your needs be served by using the SignalGenerator module instead of the FilePlayback module?

About the spatial filter, I am guessing you are following the instructions here:
http://www.bci2000.org/wiki/index.php/U ... e_Feedback

I get the same behavior as you describe so I guess the tutorial is a little out of date. If you still want to change the labels, I was able to do so by double clicking on the current label / column headers. Changing to labels from indices can help keep track of things but it is not a required step unless your classification and/or application module somehow require using a channel label instead of using channel indices.

Thanks for notifying us of the outdated tutorial. Since BCI2000 v3.0, row and column labels must be double clicked to edit, as boulay points out.

-Juergen

No worries about the spatial matrix.

We only managed to get recordings of the inital session last time we had access to the EEG, but time is quite short. So I've been working on getting file playback and the mu rhythm classified in the mean time before getting back on with the EEG.

We're attempting to control a robotic arm, and our initial session had a few extra mu stimuli, so with the .dat files the aim is to hook it up to the robotic arm on file playback and make the arm move, just to prove we have something substantial here. Obviously not an optimal solution, but resources are low, and even if it's jittering or barely working, that'll do fine for now. I realise there's extra code to write for this, but I'm only going to focus on that when the basics are sorted.

I think I've found the source of the issue with the PreRunDuration. When I set this variable to 0s, it worked, once. So maybe it's because the playback file is activating before the Run? Possibly causing it to crash, that's just a hunch though, and I'm not sure how to get round it.

(Sorry that I'm skirting your FilePlayback issues but I am not familiar with that module)

It is important to separate conceptually the classification and the application of the classifier output. The classifier outputs some number, X, that represents how motor-imagery-like your signal is. Your application then moves the robot according to some transformation of X. The transformation from input signal to X is independent of the transformation from X to robot position.

If your goal is to debug the classification (i.e., the transformation of your input signal to X) then I would start by analyzing your signal offline. If you don't have MATLAB there are other options like Octave or Python. Once you are confident in your offline feature extraction and classification then you can take those parameters online with FilePlayback. For debugging, it would probably be easier to visualize X's values directly or maybe to transform it to the position of a cursor on the screen rather than using the robot. If you can confirm that your X value or cursor position is as expected then you're done with debugging classification. You can do this in one run of FilePlayback.

If you are debugging your robot then it would be useful to generate an arbitrary X using the SignalGenerator module and a simple signal processing module. e.g. is there any set of X's that can break the robot or make it do something dangerous?

Only once you are confident in both how the input signal is transformed to X and how X is transformed into robot position should you then worry about how these two pieces interact. One question that comes to mind is whether or not you should constrain the transformation from X to robot position to make the robot movement seem more human? Based on my understanding of the literature and the results from my lab I guess that making the robot movements more human might improve acquisition (learning) of the mu-rhythm skill and is therefore a worthy goal. Some other researchers might disagree. If you want to debug the constraints required for naturalistic movement then I agree it would be useful to have FilePlayback that didn't crash.

I think I've found the source of the issue with the PreRunDuration. When I set this variable to 0s, it worked, once. So maybe it's because the playback file is activating before the Run? Possibly causing it to crash, that's just a hunch though, and I'm not sure how to get round it.

Unfortunately, this will not fix it. Rather, the error message will depend on the order in which modules connect to the operator module. There are two ways to fix the problem:
1) On the level of individual .dat files: Open the .dat file in a binary editor. At the beginning of the file, parameters are listed in clear text. Find the PreRunDuration parameter's definition. It will look similar to this: Replace the first percent sign with a zero, i.e. ascii 0x30. The error message should be gone.
2) When starting up BCI2000: Make sure the source module is the last one to connect to the operator module. I.e., use a batch file rather than BCI2000Launcher, and move the source module's line to the end of the file. Before that line, insert another line: This will wait for about 15 seconds before starting the source module, which should be enough time for the remaining modules to connect.

I will also fix the underlying cause of the problem, which consists in slightly different definitions of the PreRunDuration parameter in the FeedbackTask and StimulusTask base classes. However, a similar problem may arise for another parameter at any time, or when replaying legacy data files, so the suggested fixes above may still be necessary.

Regards,
Juergen

Hey, thanks for that. One thing though, in the .dat file's params I tried like you said, changing the first percentage to ascii 0x30, when I ran that however, none of the data was replayed, it was all blank. I changed it to dec 0 and that worked fine. I'm not sure entirely what's going on there, or whether leaving it as dec 0 is ok, but it seems to work that way.

As an aside, when playbackfile reaches the end of the .dat file it wraps around and plays it again, that causes ARSignalProcessing to crash. I'm ok without a solution to this one, it's obviously not meant to be done in the awkward way I'm doing everything, but thats just for future reference.

changing the first percentage to ascii 0x30, when I ran that however, none of the data was replayed, it was all blank. I changed it to dec 0 and that worked fine.

ASCII 0x30, or decimal 48, _is_ the '0' character. I wanted to avoid the ambiguity between 0x00, i.e. '\0', and and 0x30, i.e. '0', that's why I specified it that way.

As an aside, when playbackfile reaches the end of the .dat file it wraps around and plays it again, that causes ARSignalProcessing to crash. I'm ok without a solution to this one, it's obviously not meant to be done in the awkward way I'm doing everything, but thats just for future reference.

Can you give some details about the crash? If it indicates some kind of weakness in ARSignalProcessing, it needs to be fixed.

Regards,
Juergen

Hello,

Sorry for the late reply.

To elaborate on the issue with filePlayback wraparound. When the end of the file is reached a warning appears:
If only set config is selected and NOT start, the file sits in the background wrapping around over and over.

If start is selected and a trial is running, when it tries to wraparound an error box appears:
This creates (at an estimate) around a hundred of these boxes, holding down enter cycles through them quick enough though. I presume this is because the parameters are stored at the beginning of the file and that they are getting read at the beginning of every loop.