P300 and amplifiers

[matthieuG]

Hi,

After many try and unsuccessful experiments, at Gipsa, we succeeded. So the conclusion now is that P300-xDawn scenarios work only with specific amplifiers!

In fact, on a FirstAmp (Vamp driver), it works very well ; on a Mitsar (home made driver), it doesn't work and if the user at CICIT did right it's amplifier (TMSi driver) doesn't work either.

Can you tell me if you have the same conclusion? If you know another team who used these scenario, did they succeeded and how?

Thanks

[yrenard]

Dear matthieuG,

indeed, there could be some variations from an amplifier to another... For example, our TMSi amplifier (working with the Nexus driver) internally removes common average to all channels. This is not the case with the g.Tec gUSBamp or the Brain Products v-Amp. This means that the data coming from the "Acquisition Client" box is not necessary exactly the same from an amplifier to another, and that the scenario may be tuned to be fully functional...

However, I recommend a validation of your home-made driver(s)...
As far as I know, the TMSi driver is currently being investigated.

Hope this helps,
Yann

[matthieuG]

ok, it is a possible solution. From point of view and from signal processing, there is no difference, but the team is investigating this point... maybe more news in few weeks

[ddvlamin]

This is a very intersting topic. We had/still have our problems with the xDAWN P300 speller which we use with the TMSI amplifier. One of the things we changed in the default scenario is the reference channel box which we deleted, because (as Yann already told) the TMSI amp uses common average referencing internally.

However, I do not understand how the reference system can make the xDAWN P300 fail completely? Because one reference system can be linearly transformed into another one, I assume that a learning algorithm, such as xDAWN, can always find a good solution (for example by finding a linear transformation into a "better reference system"). Please, correct me in case this reasoning is faulty!

Given figure 5 on http://www.tmsi.com/?id=24 , assuming all feedback resistors are the same for all EEG channels and a given gain, it should be possible to manually transform the common average referenced channels into the original raw signals? This way another reference system could be chosen.

The problem we have however, is that one time we see the P300 occuring at around 300 ms and five minutes later within the same subject around 200ms. Do you experience the same problem or not?

Best regards,
Dieter Devlaminck

[yrenard]

Dear ddvlamin,

my knowledge in electronics is too limited to understand the basic figure you pointed out.

However, I should mention that we had similar issues like the bad "sync" of the P300 response. This is due to two different parameters :

• - the size of the sent buffer
  - the range in which the driver is allowed to jitter

The first parameter can be configured in the GUI of the acquisition server. The problem here is that the acquisition server always sends the entire buffer to the designer, even if the connection occured in a middle of a buffer fill. So in the worse case, we can have buffer size samples of difference between the training session and the online session. (which defaults to 32 samples / 512 Hz = 62 ms, resulting in bad P300 detection). This won't be fixed in the 0.7.0 release (should be out next week) but I hope to fix this during the summer. Meantime, you may want to try smaller buffer sizes. Find the smaller buffer size you can without loosing samples in your driver.

The second parameter can be configure with the AcquisitionServer_JitterToleranceDuration variable of the configuration file and it currently defaults to 100ms (I will put smaller a value soon). This is the range where theoretical sample count vs real sample count mismatch does not cause correction in the acquisition server. I suggest that you turn you log level to Trace and see what happens regarding to jitter with your driver.

Depending on your driver jittering, you will have to find the best combination of parameters : forcing the range to be as small as possible without causing corrections in the acquired signal (which would result in dumb "measures" anyway).

Of course all suggestions I pointed out can be tested with the latest SVN and also with next week release.

I hope this helps,
Best regards,
Yann

[ddvlamin]

Dear ddvlamin,

my knowledge in electronics is too limited to understand the basic figure you pointed out.

Mine is too limited too, but my collegue, an electrotechnician, wrote down the equations and claims that it should be possible to undo the effects of common average referencing, which is quite necessary when working with phases for example.

However, I should mention that we had similar issues like the bad "sync" of the P300 response. This is due to two different parameters :

• - the size of the sent buffer
  - the range in which the driver is allowed to jitter

The first parameter can be configured in the GUI of the acquisition server. The problem here is that the acquisition server always sends the entire buffer to the designer, even if the connection occured in a middle of a buffer fill. So in the worse case, we can have buffer size samples of difference between the training session and the online session. (which defaults to 32 samples / 512 Hz = 62 ms, resulting in bad P300 detection). This won't be fixed in the 0.7.0 release (should be out next week) but I hope to fix this during the summer. Meantime, you may want to try smaller buffer sizes. Find the smaller buffer size you can without loosing samples in your driver.

Ok, I will test this. We were using 256hz, which makes it even worse then. However I don't fully understand what you mean with the fact the acquisition server can send its entire buffer to the designer in the middle of filling the buffer. The implementation of the TMSIRefa driver contains the following code

Code: Select all

if(m_ui32SampleIndex>=m_ui32SampleCountPerSentBlock)
			{
				//sent the data block
				m_pCallback->setSamples(m_pSample);
....
}

So it waits until there are enough samples in the buffer (I used the default block size of 32).

The second parameter can be configure with the AcquisitionServer_JitterToleranceDuration variable of the configuration file and it currently defaults to 100ms (I will put smaller a value soon). This is the range where theoretical sample count vs real sample count mismatch does not cause correction in the acquisition server. I suggest that you turn you log level to Trace and see what happens regarding to jitter with your driver.

I noticed this in the code, it's indeed a nice addition. This seems to be working fine for me at first sight: it does not give me a warning when stopping the acquisition about too much jitter. However at the start of acquisition, it gives me a warning that it has to correct for around 45 samples. Then this decreases and fluctuates around zero. Could this be a problem?

Depending on your driver jittering, you will have to find the best combination of parameters : forcing the range to be as small as possible without causing corrections in the acquired signal (which would result in dumb "measures" anyway).

Of course all suggestions I pointed out can be tested with the latest SVN and also with next week release.

I will test the effect of this first parameter next week and let you know.

Thanks a lot,
Kind regards,
Dieter Devlaminck

[yrenard]

Ok, I will test this. We were using 256hz, which makes it even worse then. However I don't fully understand what you mean with the fact the acquisition server can send its entire buffer to the designer in the middle of filling the buffer. The implementation of the TMSIRefa driver contains the following code

Code: Select all

if(m_ui32SampleIndex>=m_ui32SampleCountPerSentBlock)
			{
				//sent the data block
				m_pCallback->setSamples(m_pSample);
....
}

So it waits until there are enough samples in the buffer (I used the default block size of 32).

Ok, suppose the acquisition server starts filling a new buffer of 32 samples at time t. Then suppose the designer also connects at t. The buffer will be filled at t+32 samples and sent to the designer at t+32samples as well. Now suppose the designer connects at t+31 samples. The acquisition server won't split that buffer. Therefore the designer will receive the complete buffer at t+1 sample. There is a 31 samples shift here.
Is it clear ?

I noticed this in the code, it's indeed a nice addition. This seems to be working fine for me at first sight: it does not give me a warning when stopping the acquisition about too much jitter. However at the start of acquisition, it gives me a warning that it has to correct for around 45 samples. Then this decreases and fluctuates around zero. Could this be a problem?

If it stays around 0, then its perfect. How close to 0 is it ?

Yann

[ddvlamin]

Hello,

Ok, now I understand.

We took a buffer size of 4 samples and a sample frequency of 256Hz and now it seems to work perfectly. We did 5 P300 runs and except for the first one (where a few mistakes were made) all the other runs worked perfectly.

The difference between estimated number of samples and the received number of samples is close to zeros (plus minus one).

Thanks a lot, it seems we can now start our experiments with a lot more confidence in the system.

Kind regards,
Dieter Devlaminck

[yrenard]

Dear ddvlamin,

thank you for this feedback.

I am currently working on solving this in the acquisition server.

Yann