bci2000.org BBS

Dear Forum,

I have a problem with the acquisition of the raw data using the biosemi2adc contribution. I downloaded the last version (the one found at: http://www.bci2000.org/svn/trunk/src/co ... e/Biosemi/).

I saw in the data visualization window some strange peaks while running the initial mu feedback recording (it also happens in the feedback session).

Thinking it was only a visualization problem, I opened the recorded files with the load_bcimat.m into matlab to double check. When I plot them I notice some problems. A series of horizontal lines appears at a more or less regular distance between each other. The signal of ch1 goes for a while to ch2, the one of ch2 to ch3 and the one of ch4 to ch1 (for instance). That way, the raw data is useless since those sudden changes are destroying my raw data.
I notice that changing the sampleBlockSize makes those peaks appear more often (if I decrease that value) or less often (if I increase that value), but I could not find a way to eliminate them always....

Does anyone had this problem before and could share a solution with me? I am a bit desperate

Many thanks in advance and best regards

aye [/img]

This may be the problem noted in the known-issues section of
http://www.bci2000.org/wiki/index.php/C ... iosemi2ADC
I never managed to get the system to behave well when Set Config was pressed more than once: there always seemed to be weird artefact signals of unknown origin. However, the signals always behaved well for me the very first time Set Config was pressed.

If this is the same problem, then (a) your observation that this is really the signal content jumping from channel to channel is potentially very useful for debugging and (b) the workaround would be to always quit and relaunch BCI2000 completely every time you need to "Set Config" after the first time.

Unfortunately I do not have access to Biosemi hardware at the moment, to verify this.... would have to wait at least until my next visit to Nijmegen, which may not be until Jan/Feb next year---unless anyone else wants to take over...?

Dear jhill

Many thanks for your quick reply.

I knew that issue since I read the documentation several times and moreover a message appears with a warning each time 'set config' is pressed more than once.

I forgot about it, so you reply really did solve my problem!

Many thanks

aye

Jez,

Perhaps some buffer needs to be flushed before/after the device is stopped/started?

Gerv

It certainly sounds like something of that sort, but in the short time I had to investigate along these lines, nothing obvious turned up.

I must admit, when I revised this module I left most of the calls that actually interacted with the driver untouched, and never really got to know their ins and outs. I'm fairly sure this particular problem predates me, so it probably lies in the code I never really figured out. Looking at the code now, my first suspect would be some kind of non-stateless hangover in mpBufferCursorPos, but this is a guess: would need access to the hardware to test it.

jez

Well it looks like that was probably the answer, and though we never identified the specific variable that was hanging over, Gerv has put a workaround in place that I think should be pretty solid. I had hoped for a chance to test it before I left Nijmegen this time around, but won't have time now. @aye maybe if you have the time and opportunity, svn-checkout the new version and let us know whether a real data source now looks like it behaves well after 2 x Set Config? Then you can take the hazard tape off the "Set Config" button