Timestamps of some identified clusters do not align with peak of spikes.

[linamnt]

In some of the identified clusters after running the whole pipeline, the timestamps for spikes do not represent the peak amplitude of the spikes, but seem shifted. This happens to all spikes within that cluster. See below where we plot a window 20 timepoints before and after the timestamp.

When we expanded the time window further back, we see that the timestamps do correspond to a real cell as shown below.

Thanks in advance.

[magland]

I'm not exactly certain what you are asking. But let me ask you first, are the spikes expected to be positive or negative? and what are you using for detect_sign (or spike_sign) in the parameters?

[linamnt]

Hi @magland, Thank you for your quick responses. I am wondering why the timestamp does not match with the actual peak of the spikes for some clusters? It seems to be consistent across a cluster I which this happens, as shown in the image, that the timestamp is actually delayed by a few milliseconds. The spike sign we use is 1 and mountainsort is able to correctly timestamp the peak of the spikes for other clusters identified in the same dataset. It is just one or two clusters that have this issue.

…

On Sat, Sep 15, 2018, 6:27 AM Jeremy Magland, ***@***.***> wrote: I'm not exactly certain what you are asking. But let me ask you first, are the spikes expected to be positive or negative? and what are you using for detect_sign (or spike_sign) in the parameters? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKQ2vnYw8bIjaewBtX0V1TkWuNjaZF_0ks5ubNYWgaJpZM4Wp6FR> .

[magland]

I am having trouble understanding the figures. Could you please describe in more detail. Why are there zeros?

[linamnt]

We use the Neuralynx set-up which returns a .ntt file with timestamps of potential spikes, and then stitched them together to make continuous file where the zeros are the padding around these spikes. In that case, should we be using the .ncs with just the channels x raw waveform information instead?

[magland]

Oh I see. I didn't realize you are using snippets, rather than continuous recording. In this case, you know the spike times... so ideally you should not need a detection stage for mountainsort. Somebody else was working on creating a simplified snippets version of mountainsort. How many channels do you have?

[linamnt]

We have 4 channels (it's a tetrode recording)
Just to clarify, why do you think that the spike timestamps from the stitched .ntt are not accurate given the signal-to-noise in the stitched snippets should be much higher?
Also, for now, can we use the .ncs (which is a single channel continuous file) and stitch the four channels together to use this pipeline?

Thanks!