Minimum time of recording that Kilosort can handle?

[PhantomSpike]

Hi,

Is there a minimum time necessary for Kilosort to work properly? For example, if my recording is only 5-10 mins would that be too little? Obviously more time means more data and more examples of the spike waveform so I presume it will do better, but is there a minimum?

In general, would you recommend running all stimuli and saving them as one huge Spike GLX .bin file for spike sorting or you can record them separately, concatenate them in Matlab/Python and sort them in this way? In my case for example, I am running a stimulus for finding whether the neuron is responsive to sound (white noise - 5mins), another one for the frequency tuning of the neuron (FRA - 15mins), then another more complex stimulus (complex stim - 40 mins). What would be the best approach in this case?

On the other extreme, from your personal experience, what do you find the maximum time during which you can "see/hold" the same neuron? Tens of minutes, hours, days? Are there any algorithms currently being developed for motion correction?

Cheers,

Alex

[nsteinme]

I don't think there's a minimum time but as you say longer should be better. I tend to always go for at least 30-45 minutes, but I don't have any data suggesting that shorter recordings won't also be fine.

I think either running all in one file, or stopping and concatenating, should both work fine. For simplicity I always do the former.

How long a neuron can be held really just depends on the stability of the recording... I don't have a good answer here. Yes, we've thought a lot about drift correction by "image registration" and hope to make this a reality once we have Phase 3B probes (with vertically aligned recording sites rather than checkerboard/staggered).

[greggheller]

Hi guys!

@PhantomSpike were you ever able to sort your short recordings? I'm trying to sort a 10 minute snippet we have started taking while we allow the probes to settle using Kilosort2, and I get the attached error right off the bat while its determining good channels. I'm able to sucessfully sort a longer recording that follows (no probe movement in between) but I can't get the shorter one to work. I've tried setting GPU=0, and putting in a reasonable trange=[0 500].

Any ideas?

I can concatenate with the longer one and will try that next, but for the way our processing pipeline is set up it would be nice to be able to do the 10 minute segment seperately.

settleTest_21.04.01.02.31.17_KSerror_probeA.log

[greggheller]

I was able to confirm that I can indeed sort only a 500 second segment using trange = [0 500]. But it seems like it needs a larger file to complete the initialization (although this seems strange so I'm going to continue testing, its unlikely but possible that the one test I did with small file and trange = [0 500] was not actually 500 seconds however it also failed for trang = [0 inf] ).

Is it possible that the initialization/algorithm determining good channels doesn't use the same trange? Are there parameters that affect initialization? I remember there used to be an option in kilosort1 but nothing is jumping out at me that I see.

[greggheller]

So the data in question was 642 seconds long. I was able to sort it by concatenating it to itself, and then using trange = [0 642]. So it seems like something about the initialization requires data that is longer than 10 minutes. The concatenation process is fairly quick and easy, so I will just build it into our workflow, but this seems like unintended behavior that should be noted as a bug! (Also it might be fixed in KS 3, or even 2.5, like I said, we haven't upgraded yet)