BCI2000 v3 causes problems

[OKI]

Hello,

we have some computers on witch the BCI2000 v3 does not run properly. There are different errors that occure during the runtime of BCI. In some cases the BCI runs to fast (flashes occur to fast), or the BCI sends out Round Trip time exceeds up to 90percent during the beginning.

Older versions of the BCI run fine on those machines.

Do you have any suggestions what to do?

Thanks,
Stefan

[mellinger]

Hi Stefan,

in v3, a mechanism has been added that checks whether the machine running BCI2000 can keep up with processing data. When roundtrip time approaches block duration, warnings are issued. When roundtrip time consistently exceeds block duration, the machine is definitely too slow, and processing is aborted with an error message. In older versions of BCI2000, you would simply not notice when this was the case.

Other than that, there should not be any changes in timing. You should be aware, however, that time durations need to specified with units if you want to specify them in seconds or milliseconds:

Code: Select all

StimulusDuration= 100ms

When given without a unit, time durations are taken to be in sample blocks. However, this has been the case in v2 as well, and has not changed since. Still, it might be related to your observation that "flashes occur too fast".

Also what could be the case is that initially processing is too slow to keep up with data acquisition. In that case, data will accumulate in various buffers (inside the source module, or in socket buffers between modules), and once slow processing is over, the accumulated data will be released faster than the pace of data acquisition. E.g., this could be the case when you have an initialization function that takes quite some time to complete; when processing finally starts, it will be paced too fast. Still, this should be the case in v2 as well as v3.

Best regards,
Juergen

[OKI]

Hello Mr. Mellinger,

i'm sorry to tell you that your solutions haven't fixed our problems.
The parameter files we have loaded, run fine on other systems, also we have checked them by hand.

The initially processing also seems the wrong way to fix our solutions. We have made some more expirience today.

What is causing the problem is the gUSBampSource. We just have started all modules, and see that the little source window is running with advertage speed, until it crashes after a few seconds. The other core modules run fine.

Now the gUSBampSource.exe can't be stopped by the TaskManager, in fact it even breaks the shutdown process of the computer, and we have to mannualy shut it down.

We have checked the gUSBamp driver, it is the same that runs on other machines (newest version).

Now, we suppose that the RAID system of the computer is causing the trouble?

Anyway, we have now other computers in use to test our applications, because it seems to be viewless to run the BCI version on this computer.

Best Regards,
Stefan

[mellinger]

Hello,

so you didn't have this problem when running the gUSBamp source module from v2? I would be thankful if you could post the output of

Code: Select all

gUSBampSource.exe --version

so I can determine the possible cause of the problem.

We just have started all modules, and see that the little source window is running with advertage speed, until it crashes after a few seconds.

So it crashed, and after the crash the gUSBampSource process could not be shut down in the task manager? How did it crash? Was there an error message in the Operator log window, or did the source module just stop to deliver data?

Thanks,
Mr. Mellinger

[gschalk]

Another question: do you have the gUSBamp.dll in the prog directory for the V2 installation? V3 does not come with this DLL anymore, so BCI2000 uses the one that is installed on the system (\windows\system32 I think). Thus, I am wondering whether the crashes could be related to two different versions of that DLL.

Gerv

[OKI]

Hello,

i uploaded two images that contain the informations you requested. One of them is the gUSBampSource (BCI V2) that works, the other one is the not working BCI V3 (from same Computer).

On my computer (the BCI V3 run's fine) it's using the Framework Version 3.0.0 not the 3.0.1, perhapps this is a reason.

The gUSBampSource didn't display any errors, after running very fast, it just stops (after about 10~15 seconds). We tried several times to shut it down with the Task Manager, but it didn't work. As i said, we even had to 'manually shut the computer down'.

I will check the gUSBamp.dll later that day, and report you.

Thank you for attention,
Stefan

[mellinger]

Hello,

thank you for the version information. There has been a change between version 3.0.0 and 3.0.1 that might affect behavior of the source module, though I cannot see an obvious connection right now. It would be very helpful if you could test the 3.0.0 source module on the machine that gave you the problems, and see whether it behaves better than the 3.0.1 version.

Thank you very much,
Juergen Mellinger

[OKI]

Good Morning,

i checked the BCI Directories, and the windows/system32/ directories for their *.dll datas. Here is what i found out:

1. gUSBamp.dll in win/sys32/
Firm: g.tec medical engineering GmbH
Dataversion: 3.2.0.0
Erected: 5.10.2010
Size: 220KB

2. gUSBamp_old.dll in ($BCI2000.dir)/prog/ (there was no gUSBamp.dll in that directory)
Firm: g.tec
Dataversion 1.0.0.1
Erected: 2.11.2010
Size: 128KB

of course there was no gUSBamp.dll in the BCI2000 V3 Directory.

At the moment i can't check out the Framework 3.0.0 Version on this computer, because if it crashes it will need to long time until the machine is running it's backups etc.. But as far as we can say, we already tested the Framework 3.0.0 Version (before we downloaded the Framework 3.0.1) and it also crashed.

Best wishes,
Stefan

[mellinger]

Hi,

so it seems that v2 did use the latest gTec DLL as well, and without problems. This is quite strange because there has been no change in gUSBamp-specific code between the latest v2.1 builds and the v3.0.0 build.

But as far as we can say, we already tested the Framework 3.0.0 Version (before we downloaded the Framework 3.0.1) and it also crashed.

So we can rule out the latest framework changes to be the cause of the problem. This is very helpful.

The fact that the source module could not be terminated after the crash, requiring a reboot, points to a problem that happens inside the gUSBamp kernel driver. Also, from your description of an "accelerated" BCI2000 it appears that the driver "thinks" there are data from the amplifier ready when in fact they are not. Could it be a hardware-related resource conflict with another device in the system? You mentioned something about a RAID controller that might be causing trouble?

Regards,
Juergen

[gschalk]

One possibility for trouble shooting would be to use the V2 installation with the gUSBampSource.exe from V3, or the V3 installation with the gUSBampSource.exe from V2.

This should help to figure out what's going on.

Gerv

[mellinger]

I'm not sure whether this is related to this thread, but I just identified a bug in the May 2011 3.0.1 build of the g.USBamp source module, which might have caused the described behavior. It will be fixed in future releases of BCI2000.

Juergen

[rebecacp]

I'm not sure if that is related to this problem but we have also detected a problem using g.USBamp v3 with BCI2000 v. 3.0.1. We can't visualize the recorded signal suitable and the PC finally crashed. However, whit BCI2000 v2 and v3.0.0 it doesn't happen.

[mellinger]

Rebeca,

thanks for reporting. The gUSBamp source module coming with v3.0.1 is indeed buggy, and tends to crash. Please use the source module from 3.0.0 until the next build comes out.

Juergen