Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

timestamp #77

Open
mjk1028 opened this issue Jul 31, 2017 · 2 comments
Open

timestamp #77

mjk1028 opened this issue Jul 31, 2017 · 2 comments

Comments

@mjk1028
Copy link

mjk1028 commented Jul 31, 2017

Dear again,

i found when kilosort takes openephys data, the timestamp of sorted data starts from 0 (in sec). can i know how this is exactly done? i have ttl information (stimulus on and off) via *adc1.continuous, and i am reading this info via 'load_open_ephys_data_faster' matlab function. this does not start in 0 (in sec).

both timestamps (one from matlab function- i will call this original ts, and another from kilosort after clustering) were divided by sampling rate of 30000, and the original ts was calibrated by subtracting all with original ts - original ts(1).

i expected it should be working as this, but i feel something wrong (there is significant increase of firing rate of responsive unit 1 sec before optic stimulation turned on). i would like to ask some help/advice on 1) if i am making a mistake, 2) if someone encountered the same issue and how to double check, or 3) if there is a good way to make sure these timestamps.

as always, it will be greatly appreciated. thank you!

@marius10p
Copy link
Collaborator

Hi,

Kilosort only outputs spike times in samples of raw data. To infer the timing of these spikes, you would have to infer the timing of the raw data samples. I am not familiar enough with the OpenEphys format, but maybe go on their github page and ask there? I also heard that the current OpenEphys format now outputs raw binary files, which should make it easier to import into Kilosort.

Best,
Marius

@petersaj
Copy link

petersaj commented Aug 1, 2017

Hi mjk - TTL data from open ephys can be offset from the recording start time, although this isn't always the case for me (I haven't figured out why yet - it might be pressing play and then pressing record, vs. pressing record without playing first?).

In order to correct for this, you want to subtract the recording start time from all TTL timestamps. The start time can be found in the experiment(n)_messages_0.EVENTS file, which is a text file that contains the line start time: (start time)@(sample rate)Hz.

Here's the code I use to do that, given 'messages_filename' is where the message file location:

messages_id = fopen(messages_filename);
messages_text = textscan(messages_id,'%*d %s %s', 'delimiter',{': '});
fclose(messages_id);

start_time_idx = strcmp(messages_text{1},'start time');
start_time = str2num(messages_text{2}{start_time_idx}(1:strfind(messages_text{2}{start_time_idx},'@')-1));
start_time_freq = str2num(messages_text{2}{start_time_idx}(strfind(messages_text{2}{start_time_idx},'@')+1: ...
    strfind(messages_text{2}{start_time_idx},'Hz')-1));
start_time_sec = start_time/start_time_freq;

% Get/save digital input event times, 
[sync_data, sync_timestamps, sync_info] = load_open_ephys_data_faster(sync_filename);
sync_channels = unique(sync_data);
sync = struct('timestamps',cell(size(sync_channels)),'values',cell(size(sync_channels)));
for curr_sync = 1:length(sync_channels)
    sync_events = sync_data == (sync_channels(curr_sync));
    sync(curr_sync).timestamps = sync_timestamps(sync_events);
    sync(curr_sync).values = logical(sync_info.eventId(sync_events));
    
    % correct for experiment start time
    sync(curr_sync).timestamps = sync(curr_sync).timestamps - start_time_sec;
end

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

No branches or pull requests

3 participants