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

Timing of Spikes does not match Raw Data #78

Closed
djsoper opened this issue Jun 25, 2019 · 0 comments · Fixed by #595
Closed

Timing of Spikes does not match Raw Data #78

djsoper opened this issue Jun 25, 2019 · 0 comments · Fixed by #595

Comments

@djsoper
Copy link

djsoper commented Jun 25, 2019

Hello,
I have been running Kilosort2 on some non-neuropixel electrodes, and after some setbacks, succeeded in getting Kilosort to sort them. I was satisfied with what Kilosort was finding when searching through the phy output, but when I tried to map the sorted units onto the raw data, nothing made sense. I was hoping Kilosort would capture all the fast events (less than 1ms) and then we could map them onto the raw to check correlation with slower events. As far as I can tell, every step of the process is working as expected. The only strange aspects of my setup are that the recordings are fairly short by comparison to what I see here at ~16 minutes.

Config:
ops.fs = 30000;
ops.fshigh = 250;
ops.minfr_goodchannels = 0;
ops.Th = [10 4];
ops.lam = 10;
ops.AUCsplit = 0.9;
ops.minFR = 0;
ops.momentum = [20 400];
ops.sigmaMask = 30;
ops.ThPre = 8;

I low-pass filter at 6000Hz, and then let Kilosort handle the high pass.

KiloSortExamplePEDOT

Above, I have the filtered data that Kilosort is sorting. The dots are spike times, and the color corresponds to the cluster from which that spike time came. As you can see, it's extremely regular and rhythmic. It doesn't seem to correspond to anything meaningful, as the spikes are only occasionally associated. Basically, I'm lost as to how this could be fixed, or what aspect of Kilosort/my config is causing this issue.

image

Here is another example that helped me decide that this was not just a timing offset issue. It might be not just that the timestamps are bad but the spikes themselves are poorly sorted. Here is a pic of the GUI with raw/filter on. Everything seems right to me.

KilosortGUIMG08

Any insight into this would be really helpful, as I'm still shaky on the nitty-gritty of Kilosort2.

Thank you

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

Successfully merging a pull request may close this issue.

1 participant