Cheetah captures spikes as 32 samples, and at 32KHz sampling, you usually will not capture part of a second spike during that sample window. However, if you lower your sampling rate, those 32 samples start encompassing more time. In order to detect spikes that occur during the 32 samples of a previous spike, you need to use the retrigger time on each spike acquisition entity that is affected by this issue. The retrigger time is the amount of time to wait after a spike has been detected before searching for the next spike. This setting can be useful if there are rapidly firing spikes, or echoes present on a particular acquisition entity. This avoids having portions of spikes appear in two separate records. When adjusting this value, it is best to start at a higher time and work backwards towards 1. Starting out at 1 might solve the problem, but it causes your system to do unnecessary work.
Please sign in to leave a comment.