BlackrockNeurotech/NPMK

openNSx: extra data points on NSx.Data using 't::' argument

ferchaure opened this issue · 5 comments

Hi Kian,

I have been loading ns6 files and getting an odd behaviour. If I run:

NSx = openNSx('read',filename,'t:1:2');

And then size(NSx.Data,2), I should get 2, but I got 104.
If I start the segment in any number other than 1, I don't get the extra 102 samples.

Hi Fernando,

In certain cases, the NSx and NEV files are shifted by some number of samples. This offset is recorded in the header file and when openNSx opens the file, it automatically adds the offset as zeros to the data structure and then sets the offset value in the header to 0. For example, in this case when you start recording, the NSx file starts capturing data 102 samples after the NSP clock resets. This means that the first sample is the NSx file is really recorded at time 103 (sample 1 + 102 offset) which corresponds to time 103/30k = 3.4 ms. Since the assumption is that most people will not know about this and will ignore the offset (I think it's NSx.MetaTags.TimeStamp --off the top of my head), I had NPMK automatically do this.

However, in the case that you choose a start timestamp other than 0, then adding the offset doesn't make sense. You're responsible for accounting for the the offset and also the time that you skipped to get the actual time.

Does this make sense?

Kian

sorry for the late response, thanks for the precise explanation.
I understand the simple cases now. What about ns6 files where two NSP are synchronizing and I got multiple cells of data (each with its own TimeStamp). We have been doing a few tests and It looks like if we add the last timesStamps in zeros to the last cell of data then at least this cell is aligned with the nev. Is this right? Can we do something about the other cells or that few seconds are lost?

HI Fernando, I'm not sure if I understand this. Let's set up a call to talk about this. Please let me know when is best for you here: calendly.com/ktorab/30

Best,
Kian

Also, pls send me an example data file so I can see this better. I never share the data files with anyone and I will delete it as soon as I fix the bug. Kian

Hi Kian,
It's not a bug, just an undocumented behaviour of the data recorded by 2 NSPs until they synchronize. If in each ns6 file we add the last NSx.MetaTags.TimeStamp in zeros to the last cell of its recording, the data is perfectly synchronized with the nev files. I can send you an example if you want to look at the files to check them.