-
Notifications
You must be signed in to change notification settings - Fork 176
Matlab import and timestamp issue #5
Comments
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? |
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? |
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. |
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.
The text was updated successfully, but these errors were encountered: