very irregular block duration

[PeterLiu]

Hi,

During our experiment for P3speller, the block duration appears to be very irregular:


Our setup is:
Neuroscan 4.5
Samplingrate: 1000Hz
SampleBlockSize: 40
(250Hz/10 is also tried, with similar results)
modules: Neuroscanclient, P3signalprocessing, P3Speller
winXP
CRT

I want to ask if this is going to affect the performance. More specifically, is it going to just cause a universal delay between source and stimulus (in turns of both real time and the data recorded for offline study) or it will have delay that varies at different timepoints which will have a huge impact for classification
And what we can do to alleviate this problem?

Thanks!

Yichuan

[mellinger]

Hi,

you are right that there will be an irregular time delay that impacts classification, so you should address this problem.

First, if you are running the Neuroscan software on a machine different from that running BCI2000, make sure that there are as little networking components involved as possible, i.e. eliminate all switches, hubs, etc. as far as possible. Ideally, connect both machines directly with a network cable. If at all possible, try running both the Neuroscan software, and BCI2000 on the same machine.

Second, make sure that the amplifier's hardware buffer, the Neuroscan software's packet buffer, and BCI2000 sample block size are compatible, i.e. that they all have the same size, or are integer multiples of the previous buffer in the chain. You will probably not know the amplifier's hardware buffer size, but it may be possible to vary the Neuroscan software's packet buffer size, so you should keep BCI2000 sample block size (in samples) identical to Neuroscan software packet buffer size (if given in ms, convert to samples), and vary both until timing is smooth.

Third, try the NeuroscanAccessSDK source module. It may give you better results, but may not work with all Neuroscan amplifiers.

Regards,
Juergen

[PeterLiu]

Dear Juergen,

Thank you for your suggestions. We were running both Neuroscan and BCI2000 on the same machine. On the other hand, it seems like we can not change Neuroscan's software packet buffer size (for making sure, we have contact Neuroscan and are waiting for response). And the NeruoscanAccess seem to only support newer versions of the hardware.

If all the methods you mentioned failed in our case, is it possible to correct the timing by using SourceTime and StimulusTime state? And How good it can be? Thanks!

Best,

Yichuan

[mellinger]

Dear Yichuan,

the SourceTime and StimulusTime states represent time stamps in milliseconds. The sample index also represents time, in units of the inverse sampling rate.

Time stamps wrap around each 65536 ms. Before doing the correction, you will need to account for this by adding 65536 to all further time stamps whenever the difference between two adjacent time stamps becomes negative.

Once time stamps have been corrected for wraparound, you may compute a time stamp for each sample by determining a line of regression for the SourceTime state, with the sample index as a regressor. The line of regression gives you the time stamp for each sample. (http://en.wikipedia.org/wiki/Simple_linear_regression)

Then, you may match the StimulusTime time stamp with the sample time stamp in order to determine the sample position at which the stimulus was actually presented.

Regards,
Juergen

[PeterLiu]

Thanks for the reply Juergen
I tried our setup on another PC (still XP). and the result is as follows:

It seems like the block duration first dropped to near zeros. I figure that it might be Neuroscan Acquire sent two data packages in that 40ms block instead of one. but how could that be possible?

[mellinger]

I agree that it appears as if Neuroscan Acquire were sending two packets at once from time to time. Also, it seems that no packets are dropped, or duplicated, because average packet duration remains correct.

I've double checked the NeuroscanClient code, and found nothing that might explain such behavior on the BCI2000 side.

If the problem lies on the Neuroscan Acquire side, it might be related to system load, and thread timing. As an experiment, you might run Acquire on a second machine, and use a direct cable connection to the BCI2000 machine.

Also, are you using the most recent Neuroscan Acquire program version available?

-Juergen

[PeterLiu]

Dear Juergen

We wrote a standalone program to receive packages from neuroscan Acquire directly and monitor the interval between the arrival of two packages, here is the result:


No software other than Neuroscan acquire is running.
The average interval is exactly 40ms. However, the intervals appears to be very irregular. I think this is the source of our problem.

To solve it we decided to modify the P3speller module so that a trigger signal will be sent through parallel port to our NuAmp amplifier right before the stimulus onset:

StimulusTask::Process
...
/* fall through */
case ISI:
{
if( mStimulusCode > 0 )
{ // Enter stimulus phase
if( ParallelPortOn==1)
{
// sent the stimulus code through parallel port to NuAmp
Out32(ParallelPortAddress,mStimulusCode);
}
mBlocksSinceStimulus = 0;
State( "StimulusCode" ) = mStimulusCode;
State( "StimulusType" ) = mAssociations[ mStimulusCode ].Contains( AttendedTarget() );
bcidbg( 2 ) << "Event: StimulusBegin for stimulus code #" << mStimulusCode << endl;
OnStimulusBegin( mStimulusCode );
mCodesPresented.insert( mStimulusCode );
mPhase = stimulus;
}
else
{ // Enter post sequence phase
State( "PhaseInSequence" ) = PhaseInSequence::PostSequence;
mPhase = postSequence;
}
} break;
...

And we are planing to add an event channel to the Source module for receiving the timing of the stimulus onset from the NuAmp

What's your opinion? Thanks.

Yichuan

[mellinger]

And we are planing to add an event channel to the Source module for receiving the timing of the stimulus onset from the NuAmp

What's your opinion? Thanks.

Sure, you can do that, but for offline analysis, it will not have any advantage over the regression method that I described in an earlier post.

For online classification, you would need to modify the P3TemporalFilter such that it watches an additional state, e.g. NuAmpStimulusCode rather than the StimulusCode state to determine epoch onset. Also, in your source module modification, you will need to set the NuAmpStimulusCode from the trigger channel rather than using an additional signal channel.

Regards,
Juergen