Open macstry opened 9 years ago
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? Thanks!
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)
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.