Wrong timestamp

[somalcy]

Hi, when I use the example to read our data, I find the full timestamps give strange value. It should be 0 to 2 sec if I ask for data with 2 seconds time window. But the t is about 5.62434901e+13, so what is the true timestamp of the data.

Here is the output figure

[somalcy]

I remove start_time_s to get cont_data and find start_time_s in cont_data is set to 2.0. Is that means the first timestamp is 2 seconds rather than 0?

[cboulay]

Are you using a Gemini device? (smaller, digital only platform)

If yes then the timestamps may be in nanoseconds. Try subtracting the start time (as you’ve done) then dividing by 1e9. Do they look more reasonable now?

Check ‘1 / np.median(np.diff(corrected_timestamps))’ to see if it matches the expected sample rate.

[somalcy]

I'm not sure. We both have the blackrock hub and nsp system. The screen on the nsp will show the word 'Gemini'. Is that a Gemini device?

[somalcy]

After I subtract the start time, each sample time is multiples of 33320. How to transform it to second unit?

[somalcy]

And I find the nev file with ‘nsp’ prefix gives timestamps of digital input marker, but the timestamps in ns6 file with 'Hub' prefix also gives timestamps of recoring data. These kinds of timestamps show totally different scale. How to align them?

[cboulay]

After I subtract the start time, each sample time is multiples of 33320. How to transform it to second unit?

OK you have a Gemini. The Hub timestamps are in nanoseconds. Just divide by 1e9 to get seconds.

Someone will answer you about the NSP timestamps being in clock-ticks.

[somalcy]

I got it. The timestamps are just nano seconds and I don't need to divide sample rate. Can I get the NSP time answer in this issue?

[cboulay]

Please contact Blackrock support to resolve the issue with the NSP. It is a known problem and they have a solution.