bci2000.org BBS

I'm curious if anyone can explain the finer points of the timing involved with the Process function and BCI2000.

Background:

I've developed a new Source Module that connects EMG electrodes to our system via USB input. The block size of our Source Module *must* be set to 20 in order for it to function. Our electrodes record at 2000 Hz, effectively setting the sampling block of the source to 10 ms.

The problem:

There's a gradually-increasing delay in the entire system - but this delay only begins once I hit "Start" to run the protocol. (There is no delay after I hit "Set Config".) The degree of the delay during the run depends on what Signal Processing Module I put with our Source Module.

Attempted solutions to date:

My initial reaction is that there are two likely sources of errors: the Source Module and our Signal Processing Modules. I believe I've ruled out the Signal Processing module as the source of the gradually-increasing delay, as the delay exists even when I pair the Source Module with the DummySignalProcessing module. Moreover, we've never had any issues with our Signal Processing modules before with this. So all signs point towards my new Source Module.

From what I understand, the Source Module is effectively clocking the BCI2000 system at a rate of 1000 Hz, which seems like it might overload the software. (I'm not sure why this would only be an issue once I hit "Start".) However, I've tried to change both the sampling rate and the block size with varying (unsuccessful) results. If I increase (or decrease) the sample block size, I'll get something that looks like a half square-wave, half actual-EMG-signal - it seems to not copy everything over from our hardware/USB-input correctly. I'm unsure if the sample block size of 20 is something that's hard-wired into our electrode / USB system. If I decrease the sampling rate, BCI2000 incorrectly speeds up the time (i.e. 2 s window of source signal -> zooms through in only 1 s).

If anyone has experience dealing with this kind of problem - or any crazy ideas to try - I'll listen to anything at this point!

Thanks!

There are a few things that happen per-block during running that don't happen in between runs. The data are written to disk, the data are sent through the filter chain, and there are probably more.

Are you using a commercial USB DAQ like one from Measurement Computing or Contec? I've written source modules for both of those and had some success.

I think I'm missing something. You say you're sampling at 2 Khz and your sample block size is 20, so you are attempting to run BCI2000 at 100 Hz, not 1000 Hz, correct?

The limit of 20 samples is a little strange. Usually the limitation on the number of samples per block (SPB) has to do with the size of the DAQ's internal buffer and the data type it's using. This often results in NChans*SPB = multiple of 32.

Without having the hardware to test I can't really guess much beyond that.

I do have an idea of something you could try. You can restrict your SPB parameter to be a multiple of 20 (SPB/20 = k). Then, during process, you can poll the hardware k times, copying the data into 1/kth of your output each time, but not returning until you've iterated k times.

mugs wrote:If I decrease the sampling rate, BCI2000 incorrectly speeds up the time (i.e. 2 s window of source signal -> zooms through in only 1 s).

I've seen this before. It happens when you're DAQ API is non-blocking. i.e., you ask for 20 samples, it only has 10, it returns anyway instead of waiting until there are 20. A way to get around a non-blocking API is to write a while(new_samples < X){new_samples = how_many_samples();} loop before copying the data from the DAQ.

If your DAQ is commercial and the API is publicly available then please link it here.

Mugs,

if compiled in release mode, you should be able to clock the BCI2000 framework at 100 Hz. If you not already have tried this, please compile in release mode.

If this does not change anything, there are two pieces of information that I would need you to gather, before I can narrow down on the potential issue:

(1) Can you please post a picture what the BCI2000 timing window [1] shows during run? Please do this once when compiled in release and once when compiled in debug mode.

(2) Can you describe and if necessary timestamp your SDK calls? For example, does your SDK perform a callback or does BCI2000 call a blocking SDK function that return once 20 samples are accumulated? If it is a blocking function, can you please use a high precision timer [2] to create timestamps before and after the call. The timestamps difference should on average be exactly 10ms.

Please let me know what you find.

Regards, Peter

[1] http://www.bci2000.org/wiki/index.php/U ... nce:Timing
[2] https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

Thanks a ton to pbrunner & boulay for the helpful tips - things are now running smoothly. Your help was essential to solving the problem. Here's what worked & what didn't:

What worked:
1: Changing (increasing) the length of a temporary variable that copies characters from the Windows socket. (I unfortunately forgot to mention that this runs entirely through a Windows Socket.) I also had to ensure that the blocking while-loop I wrote allowed for the length of the longer variable to copy over from the Socket.
2: Changing the block size *within the Source Module code only* to be a multiple of 20. Strangely, changing the block size within the config file from 20 (to a multiple of 20) elicits the original error.

What didn't work:
Compiling in release mode (vs. Debug mode) - this had no apparent effect on performance.

Miscellaneous:
1: Interestingly, the Timing Window almost never displays a completely flat line - the BlockSize always varying around 10ms.
2: I had a typo in my original post - 100 Hz (not 1000 Hz!)
3: I'll be happy to share this Source Module in the next few weeks.

Thanks for the help,
mugs

Mugs,

I am glad that the problems have all been resolved.

3: I'll be happy to share this Source Module in the next few weeks.

Please touch base with me once your code is ready to be contributed. I will walk you through the process.

Regards, Peter