Replies: 1 comment
-
|
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
There are two steps, in the first step, spikeCodes are calculated in which fractionConcurrent and fractionConcurrentPrecise are created and saved in
*spikeCodes.mat. In the second step, calculate the probability the spike is real based onfractionConcurrentandchannelsConcurrentPrecise(notfractionConcurrentPrecise). So far, I do not seechannelsConcurrentPrecisecreated or saved, and neitherfractionConcurrentPreciseis used in spike rejection.As shown here:
nwbPipeline/src/spikeSort/getSpikeCodes.m
Lines 118 to 126 in 968f332
nwbPipeline/src/spikeSort/getSpikesToReject.m
Lines 74 to 75 in 968f332
nwbPipeline/src/spikeSort/createBinEdge.m
Lines 5 to 6 in 968f332
Spike rejection uses the 3ms time window to reject spikes across all the channels. It will be rejected if more than 50% of channels have spikes within the time window. For the precise time window (2000/SR), if there are more than 6 channels that have spikes, it will be rejected.
In addition, these values are converted to a probability that is multiplied by the probability derived from other features. The threshold for spike rejection is determined by the turning point of the curve of probabilities for all channels.
It seems the precise time window
fractionConcurrentPreciseis not applied in rejecting spikes. Spike rejection checks ifchannelsConcurrentPreciseexists in the spike code, if not it will not be considered.fractionConcurrentPreciseis also calculated based on all channels across all bundles.Beta Was this translation helpful? Give feedback.
All reactions