BUG: Drift Correction when using capacitance-based lickometer

[pstarski]

Describe the issue:

Hi,

I use an Arduino-based, capacitance lickometer that sends an electrical signal each time the water bottle spout is touched. This signal introduces excess noise in my recordings, which I previously removed while working with 32-wire multi-unit arrays using Phy2’s raw amplitude view for curation. My current recordings, however, use Cambridge NeuroTech’s 64-channel E2 Assy-156 probes targeting the anterior insula. These sessions are relatively short (about 10 minutes), with a maximum of 4 minutes of licking.

In the past, when working with wired MUAs, I successfully used Kilosort2 to curate out obvious noise and extract quality units. However, since the addition of drift correction, I believe the capacitance charge is now causing errors in the sorting process.

Below I have two examples:

Example A does not use the lickometer

Example B uses the lickometer

In the drift_amount plot, the location where the drift occurs directly coincides with the drinking activity of the rat.

Example A Lickometer

Example B No Lickometer

Here are params.py files to see the sorting result in phy2.
Starski_lickometer.zip

Any help diagnose this issue would be greatly appreaciated. I will provide any additional information if needed.

Reproduce the bug:

No response

Error message:

No response

Version information:

Anaconda3

Kilosort4

OS Name Microsoft Windows 10 Enterprise
Version 10.0.19045 Build 19045
OS Manufacturer Microsoft Corporation
System Manufacturer Dell Inc.
System Model Precision 5820 Tower
System Type x64-based PC
Processor Intel(R) Xeon(R) W-2265 CPU @ 3.50GHz, 3504 Mhz, 12 Core(s), 24 Logical Processor(s)
BIOS Version/Date Dell Inc. 2.14.0, 12/16/2021
SMBIOS Version 3.2
Embedded Controller Version 255.255
BIOS Mode UEFI
BaseBoard Manufacturer Dell Inc.
Platform Role Enterprise Server
Windows Directory C:\windows
System Directory C:\windows\system32
Boot Device \Device\HarddiskVolume5
Installed Physical Memory (RAM) 64.0 GB
Total Physical Memory 63.7 GB
Total Virtual Memory 73.2 GB
NVIDIA Quadro RTX 5000
NVIDIA Quadro RTX 5000

[jacobpennington]

@pstarski Can you please try sorting with drift correction disabled, by setting nblocks=0, to see if that corrects the issue? Just to confirm that that is the problem.

[chris-angeloni]

Not a solution to the sorting problem, but I had this issue as well, and I highly suggest switching to an all optical lick detection system.

Commercial variants seem quite expensive for what they are, but the components are super cheap and not very hard to DIY if you are comfortable with soldering.

Here is a published approach, possibly overcomplicated: https://www.eneuro.org/content/11/7/ENEURO.0189-24.2024

Here is an excellent DIY approach that I've based mine off of:
https://brianisett.com/2016/03/26/diy-lickometer/

Here is an even more basic approach showing how to use cheap optointerrupters:
https://www.martyncurrey.com/connecting-an-photo-interrupter-to-an-arduino/

[pstarski]

@jacobpennington sorry for the delay, was traveling a lot. I turned off the drift correction and I think that works best. However, I also get kilosort thinking that the capacitance noise is all 'good' clustering (see image). Do you know how I can possibly eliminate this? Like 25% of the clusters end up like this.

@chris-angeloni super cool paper and great thought. Our work relies heavily on the licking microstructure and needs to record every individual lick. I may try this in the future though and I am glad you shared it.

[jacobpennington]

@pstarski There isn't any setting to address that unfortunately. If there are large, consistent fluctuations in the data, those are likely going to be identified as good units. The ideal solution would be to do some form of preprocessing to remove those events from the data before using KS4. Alternatively, you can try setting the artifact_threshold parameter which will zero out those batches.