Drift continually increasing

Obtaining data from various hardware devices
Post Reply
claytonidestae
Posts: 3
Joined: Sat Oct 21, 2017 7:13 pm

Drift continually increasing

Post by claytonidestae »

Hello,
I am working with an OpenBCI headset with openvibe to collect some data, but every time I connect the headset to the acquisition server, the drift is far too high on the early side of the spectrum. Additionally, the drift increases linearly with time. As I am writing this, I have let it run for about ten minutes and the drift is a full second early. I think this is because I am using an old computer that is processing the data slower than it is being sent. Is there a way to correct this or do I simply need to get a newer system?

Note: I am using ubuntu 16.2 and Openvibe v2.0.0 and I am only concerned about collecting the data (as long as it is still accurate, I am willing to ignore the time difference)

Edit: Is suppose the better question is this: if the drift is off by less than 2 seconds, can I still work with this data to make a classifier? If so, can this data still be considered accurate?

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

Re: Drift continually increasing

Post by jtlindgren »

Hi,

if a driver is well developed, Acquisition Server and the driver should require very little CPU. I doubt very highly the lack of computational power would be the issue here. Unless of course the system is swapping memory or such.

Instead I assume that what you see is due to the fact that Openvibe 2.0 no longer masks the driver/server clock difference by default. The previous versions did this kind of masking with 'drift correction', that either truncated or padded the data when there was observed to be too much or too little of it. This feature can be nevertheless enabled but it will tamper with the signal, and I wouldn't recommend it unless it definitely seems to give better results. If you have drift correction enabled, watch out for GDF_Correct, GDF_Incorrect stimulations in the output. These will mark times where the signal has been ruined by the drift correction, either by adding or removing samples.

The relationship between sampling frequency f, time t and number of samples s is

ft = s

If you receive k extra samples, you have

ft = s + k

Solving the above for f, gives f = (s+k)/t. Lets assume your sampling rate is 512hz (you can use your own numbers). Now if AS says the drift is 1s (early), it means there is 1sec worth of too much data at 512hz. This is 512 samples. Setting t=10min the expected amount of data is s = 10*60*512 samples. Putting these together, we get

f = (307200 + 512) / (60*10sec) = 512.85hz,

that is, from the viewpoint of the server's clock, the acquisition device doesn't have a sampling rate of 512. This doesn't mean there's anything wrong with the signal. There's nothing to 'correct', it just means the two pieces of hardware have a different concept of time. Its possible that in the long term any two devices will have slightly different clocks, especially since the sampling rate is forced to be an integer, hopefully the nearest one.

The key reason (as far as I understand, anybody feel free to chime in) why this kind of clock difference shouldn't matter is that we are assuming in OpenViBE that hardware or software tagging are always used to add markers to the EEG data. Since neither the Acquisition Server or the device accumulate data buffers (at least they shouldn't), what should happen is that when something happens, a marker (stimulation in OpenVibE) of this something is immediately sent to the Acquisition Server (TCP Tagging) or the device (hardware tagging, you need to do custom dev to get this) which then matches it with the data as its being read. Usually this is immediate, i.e. box sends a marker with time 0 to AS after rendering some event and AS attaches it (more or less) to the sample which arrived at the same time with the reception of the marker. To put it another way, usually in BCI we are interested in some segment like [now,now+t]. If now means now, it doesn't matter how many samples appeared before now, neither does it matter how many samples are obtained after [now+t]. The region of interest in time is local.

On the Designer side, if at time t more samples have been received than is expected by the sampling rate, what happens is that the chunk timestamps will run faster than the Designer time. For example, if 'real' sampling rate is 1024 and declared rate is 512, the chunks will be stamped with the assumed rate as they come, so at playback time of 1s, Designer will have received chunks with timestamps up to 2s (since there's 2s worth of data). What effects this will cause is not totally clear yet.

We're currently investigating the consequences of clock difference. For many years the followed paradigm was to use the 'drift correction'. Later we've started to suspect that the optimal way to address differences in the clocks might not be to destroy the signal more or less arbitrarily because there's too much or too little of it according to the receiving computer. The jury is still out regarding the best way to handle this. If anybody knows 'the best way', don't hesitate to share the knowledge.

Finally, to answer your question, if the markers are placed appropriately, it should work. If you export data from OpenViBE, what you should see is that the samples are timed in the output format as if the sampling rate had been exactly what it was declared to be. As long as you do analysis like 'take data starting from this marker, ending at that marker' and the true sampling rate is reasonably close to the declared sampling rate, it should work. But in analyses like 'take data starting from 24h', the declared frequency might mislead where that 24h point really is in your data.

ps. another way to look at you situation is relative. 1sec is not much of a skew over 10min. Its something like 0.16%, about 1/5 of a percent.
ps2. changed the topic, I don't think its about tolerance increasing, but the drift measure. Right?

Hope this helps,
Jussi

jack_fog
Posts: 1
Joined: Fri Sep 02, 2022 1:30 am

Re: Drift continually increasing

Post by jack_fog »

Hi Jussi,

Could you please clarify your recommendations for drift correction with EEG data? My understanding is that if we want true timing of the signal and events then we should avoid drift correction. Is that correct?

I also wonder if it is ideal to match the acquisition server 'sample count per block' to the sampling rate of the device to improve the detection of potential drift. For example, if the sampling rate of the EEG is 250Hz, would it be optimal to have a block size of 250 to enable the acquisition server to better estimate of the expected number of points per second?

Thank you,
Jack

Thomas
Posts: 210
Joined: Wed Mar 04, 2020 3:38 pm

Re: Drift continually increasing

Post by Thomas »

Hi Jack,

I am replying here as Jussi is not working on OpenViBE anymore.

To confirm, in general, yes it is better to avoid drift correction as it can potentially pad or trim the data, meaning that the data is corrupted.
As Jussi explained, the drift that is seen is due to small clock differences and should therefore be minimal, as should be the sample drift. And therefore the tagging of the signal should still be accurate and pointing at the correct data.

I think your idea of matching the "sample count per block" to the sampling rate of the device would allow to get the drift in a clever way.
However, the "sample count per block" has to be a power of two value, and all sampling rates might not be. Doing this would also mean that a block of data goes out of the acquisition server only every second, which might not be enough for some applications where live feedback is needed.

Hope my message helps.

All the best,
Thomas

Post Reply