Sychronisation of neural data

[Guifen Chen]

Dear OpenEpys developers, 

We're currently writing our own plugins to save neural data and ttl to a format compatible with our existing pipeline. 

However, it seems that we have some synchronisation issue. On average, one out of several recordings, the neural signal is delayed for about 0.4s, compared to TTL/position data. We are confident with the delay, since the results/activity patterns seem right when we move the neural data forward by 0.4s compared to TTL/position data. This doesn't happen every time, so we could not figure out what led to the seemingly-random delays.. 

We wonder if others have encountered something similar or have any suggestions.. 

We use the following line to get startingTimestamp when calling void RecordEnginePlugin::writeTimestampSyncText(),

startingTimestamp = static_cast<double>(sampleNumber) / sourceSampleRate;

Our understanding is that this function gets called only once and the result serves for both TTL and neural data. Is that correct?  

We then use the following functions to save TTL and spikes. Is there a chance that the two somehow arrives in a different way and leads to the issue... 

writeEvent()

        str_stream << "ttl_" << (ttl->getLine()+1) << " "
                   << (eventStruct->getTimestampInSeconds() - startingTimestamp) << " "
                   << (ttl->getState() ? '1' : '0') << "\r\n";

and writeSpike()

int32_t timestamp = BSWAP32(static_cast<int32_t>((spike->getTimestampInSeconds() - startingTimestamp) * timestampTimebase));

Here is the entire code. 

https://github.com/d1manson/open-ephys-plugin-ltx/blob/main/Source/LTXRecordEnginePlugin.cpp#L322

Thank you in advance for any advice. 

Best,

Guifen

[Josh Siegle]

Hi Guifen,

It looks like the continuous data writer is shifting the timestamps by the `posFirstTimestamp` variable, while the event/spike data is being shifted by `startingTimestamp`.  Upon initialization, `posFirstTimestamp` is being set to the first value in the data buffer, rather than the float timestamp buffer (ftsBuffer). Could that account for the discrepancy?

I would also recommend *not* shifting any of the timestamps prior to writing, and instead using the values of event, spike, and continuous timestamps that come directly from the Record Node. That way if recording is stopped and started while acquisition is active, the timestamps will remain consistent between recordings.

Josh

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/open-ephys/17a9ffa7-6196-4b3d-a47d-af93938398fen%40googlegroups.com.