Skip to content
This repository has been archived by the owner on Mar 20, 2024. It is now read-only.

Matlab import and timestamp issue #5

Open
macstry opened this issue Apr 23, 2015 · 3 comments
Open

Matlab import and timestamp issue #5

macstry opened this issue Apr 23, 2015 · 3 comments

Comments

@macstry
Copy link

macstry commented Apr 23, 2015

I was analyzing my continuous LFP data and trying to line-up manual timestamps that I had placed during recording (via comments entered in the GUI and pressing 'save',) when I noticed that clear events on the recording were not lining up with the timestamp. For a number of my recordings, I had hit the play button prior to hitting the record button in the GUI to make sure that I had a good signal before recording. I was wondering whether the timestamp on the messages.events file related to the sample number on the actual recording or the overall sample number (including non-recorded time). I did a test where I did a number of timestamps, paused the recording, and did additional timestamps. From that data, it looks like the timestamp includes non-recorded time (which means that the int64 stamp doesn't actually correspond to sample number in the recording.) I have a lot of data that hinges on accurate timestamps and is already recorded- is there any way to determine how these timestamps line up? It looks like the load_open_ephys.m reads the int64 timestamp in the .continuous files, which is what I believe is in the messages.events file, but I'm not clear how to correlate everything. Any help appreciated.

@jsiegle
Copy link
Member

jsiegle commented Apr 25, 2015

The timestamps are saved as samples since the start of acquisition (when you hit the play button), and the loading code converts them to seconds. So if you stop recording while acquisition is active, the timestamps will continue to increment. Does that agree with what you're seeing?

@macstry
Copy link
Author

macstry commented Apr 28, 2015

Yes, that's exactly what I'm seeing, and where I'm running into a problem is trying to convert the timestamp in the messages.events file to either the correct sample number corresponding to the sample in the imported 'data' array OR to convert that uint64 timestamp to the seconds timestamp vector that you get when you import .continuous files using the load_open_ephys_data. When you use the manual message entry in the GUI, it doesn't place anything in the all_channels.events file, so loading that file only gave the header without the relevant info/timestamp info from the messages.events file. Any suggestions?
Thanks!

@aacuevas
Copy link
Collaborator

Entrying manual messaged in the GUI does create an entry on the all_channels.events, look for those whose eventId is 5 (which are messages) instead of 3 (TTL). Converting the timestamps of the message files to seconds by dividing them by the sample rate gives the same times as long as the timestamp source for those is set to the hardware one. Right click on the message center to change the timestamp source.
Bear in mind, though, that it's impossible to align messages to a specific sample. As the GUI processes the data in blocks of max 1024 samples, events coming from different sources with no means of synchronization, like manual or network messages, are aligned to the start of the hardware block. (Other event sources that generate them from the signal itself, like the phase detector, are indeedsample aligned, as hey use the signal as synchronization)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants