Target Response Box Sampling Rate

Concerning processing components: filters, file load/save, visualizations, communication ...
Post Reply
jaspreetranjit
Posts: 7
Joined: Fri Dec 25, 2015 5:59 pm

Target Response Box Sampling Rate

Post by jaspreetranjit »

Hi,
I am new to Openvibe, I am working with the p300 xDAWN scenarios. So far, I have connected my Emotiv Epoc + headset to the acquisition server, I have collected the initial data and trained one letter with the p300 xdawn-1acquisition.xml. I opened p300-XDAWN-2-train.xml to read data from the .ov recorded file, after running this in fast mode, I opened the p300-xdawn-3train-classifier.xml and made generic stream reader read that same .ov file, I ran that in fast mode. However, I received two warnings stating:

"[WARNING] At time 15.086 sec <Box algorithm::(0x000012c5, 0x00004d5a) aka Target response> Sampling rate [31] suggested by chunk properties differs from stream-specified rate [32]. There may be a problem with an upstream box. Trying to use the estimated rate.
[WARNING] At time 30.086 sec <Box algorithm::(0x000012c5, 0x00004d5a) aka Target response> Your signal does not appear to be continuous in time. Previously inserted buffer ended at 29.6621s, the current starts at 29.3672s. The display may be incorrect."


I have been following this open vibe thread: viewtopic.php?f=17&t=401
specifically this section:

"I suggest you to use the p300-speller-xDAWN, it has better result than the p300-speller.
First, for the acquisition, it's better to use this process:
Learn one letter with the “p300-speller-1-acquisition.xml” scenarios, for this, in the line 8 of the file “p300-speller-stimulation.cfg” changed the SettingValue by 1.
Next, in the scenario “p300-speller-2-train-xDAWN.xml” load the file “${Path_Samples}/signals/p300-speller-xdawn-1-[Record_Date].ov” and start the player in fast mode.
For the scenario “p300-speller-3-train-classifier.xml” load the same file and start the player in fast mode.
This process initializes your configurations files.

For learning, used the “p300-speller-4-online.xml” with 10 letters (in the line 8 of the file “p300-speller-stimulation.cfg” changed the SettingValue by 10).
Next, used scenarios “p300-speller-2-train-xDAWN.xml” and “p300-speller-3-train-classifier.xml” with the newest record in the "signals" folder. You can see in the console the classification percent. For a good result this value need to be better than 83,3%.
To finish you can make your test with the “p300-speller-4-online.xml” scenarios."


to make the p300 scenarios work. How do I fix those warnings and match the sampling rate with the stream specified rate and how can I get it to run continuously.
Thank you so much for your time and any help will be greatly appreciated!

Best,
Jaspreet

jtlindgren
Posts: 775
Joined: Tue Dec 04, 2012 3:53 pm
Location: INRIA Rennes, FRANCE

Re: Target Response Box Sampling Rate

Post by jtlindgren »

Hello Jaspreet,

those warnings are Signal Display's way of saying that it expects a continuous signal. Although it can display a noncontinuous one, this usually looks a bit funny and we've put the warning there to alert that there might be something fishy going on. And indeed in this case there appears to be.

The first warning appears to come from the configuration of feeding the chain with the following combo that is normal for Emotiv Epoc: 128hz signal, 32 sample chunk size, and decimation rate of 4, and then using Stimulation Based Epoching box with parameters 0.6 and 0. It appears that in these conditions the box doesn't produce a stream where the chunk properties and the sampling rate agreed. However, its not clear if the resulting stream is indeed broken in its contents in a way that it'd harm the further processing, or if its just an anomaly in the chunk description.

The second warning likely comes from the epoching boxes as well, but its normal. With epoching, it happens that the signal becomes noncontinuous if the epochs overlap or underlap. This is not a problem.

Fixing a possible bug in the epoching might take a bit, but you might try to compare how the thing behaves with and without the Signal Decimation boxes in the pipeline, and if removing that box gets rid of the error. You can also replace data reading from the file with e.g. Sinus Oscillator box and change the sampling freq and chunk size and see if some combo makes the warnings disappear. With Epoc, you should at least be able to change the chunk size in AS. You can also try to fine-tune the epoching time params.


Cheers,
Jussi

sahanajoshi
Posts: 1
Joined: Fri Mar 23, 2018 12:15 pm

Re: Target Response Box Sampling Rate

Post by sahanajoshi »

Hi ,
I am facing the same warning, however my situation is different. I am reading data from a CSV File Reader box(this data was recorded on OpenVibe at a sampling rate of 250Hz). This data is given to a Python Scripting Box, which contains a custom code for filtering the signals. The output of this box is given to a Signal Display Box and the Signal Display box is throwing this warning.

jtlindgren
Posts: 775
Joined: Tue Dec 04, 2012 3:53 pm
Location: INRIA Rennes, FRANCE

Re: Target Response Box Sampling Rate

Post by jtlindgren »

Hi Sahana, here's the error printing computation logic in pseucode,

Code: Select all

if(bufferStartTime < lastBufferEndTime)
    -> print 'Your signal does not appear to be continuous in time'
and

Code: Select all

bufferDuration = bufferEndTime - bufferStartTime;
estimatedFrequency = (numSamplesInBuffer / bufferDuration );
if(samplingFrequency != estimatedFrequency)
     -> print 'suggested by chunk properties differs from stream specified rate'
This means that you need to set, in the python script, the declaration of the sampling frequency (in the stream header) to match bufferSize/(bufferEnd-bufferStart) and make sure each chunks bufferstart is the same as the previous chunks endtime. To put it another way, sampling frequency and chunk size and timestamps must be compatible. If your script changes any of these, the others must be changed to match or signal display will complain. If your output stream is intended to be noncontinuous or overlapping, then there is no problem.


Hope this helps,
Jussi

Post Reply