Spike sorting & PSTH

Real time spike sorting

Real time spike sorting capabilities will greatly improve the usability of the system for acute experiments. Real time spike sorting algorithms generally fall into two categories, one that use the wave forms directly (e.g. box or vertical line method) and methods that use PCA space.

Currently, both the box method and PCA method are implemented in a new Spike Detector processor:

The box method allows to create as many units as you want. Each unit can have one or more boxes. A wave form is considered to belong to a specific unit only if it intersects all of its boxes.

The PCA shows the two largest principal components of the spike wave form covariance matrix. Units are defined as polygons in this space. Each unit can only have a single polygon.

Both techniques can be use in parallel, but the PCA method has priority. In other words, if a spike fits a pca polygon and a box unit, it will be assigned to the pca unit.

Sorted unit information (which electrode, which unique unit ID, color) are stored in the spike object that is passed on the pipeline. 

Network Events

The network event module listens over the network on a specific port. Implementation is based on the widely used 0MQ library. 

Special commands will  be transferred to other modules (e.g. remote start/stop recording, etc).

The network event module sends incoming messages on the pipeline using the midi buffer, with a special NETWORK event code.

Peristimulus time histogram (PSTH) sink

The PSTH sink module is used to display average firing rate and average lfp, aligned to external events, such as TTL pulses, or more complex trials that are sent over the network.

The module uses the following commands that are sent using the Network Events module:

1. ClearDesign
   1. This command clears up all known conditions
2. NewDesign <design name>
   1. This command clears up all known conditions, and set up a name for the active "design". A design has any number of conditions. A condition has any number of trial types, and specific outcomes. See more below.
3. AddCondition Name <condition name> TrialTypes <trial types> Outcomes <trial outcomes>
   
   1. This command add a new condition to the active design. The condition will average spike & lfp information only for trials that belong to the subset of trials defined in <trial types>. 
   2. A trial type is any positive integer. 
   3. You can further define whether to average a trial or not by its outcome. Outcomes can correspond to correct/incorrect, or any other response the animal makes. 
   4. Outcomes can be any positive integer.
4. TrialStart <trial type, optional> 
   1. This command indicates that a trial has started. You can send (optionally) the trial type here as well. Otherwise, use the TrialType command
5. TrialType <trial type>
   1. This command sends the trial type information of the current running trial.
6. TrialAlign
   1. Spikes & LFP can be aligned not only to trial onset, but to other events (i.e., saccades, lever presses, etc). Use this command to indicate that firing rate should be aligned to the specific time point when this command was arrived.
   2. If TrialAlign command is not sent for a trial, the default is to average things relative to TrialStart
7. TrialOutcome <trial outcome>
   1. This commands indicate the outcome of the trial.
8. TrialEnd <trial outcome, optional>
   1. This indicates that a trial has finished, with the optional parameter that indicates what was the outcome.
      
      

For example, a two alternative force choice task, with four conditions can be constructed like this:

NewDesign 2AFC

AddCondition Name GoLeft TrialTypes 1

AddCondition Name GoRight TrialTypes 2

AddCondition Name AllTrials TrialTypes 1 2

AddCondition Name GoRightCorrect TrialTypes 2 Outcomes 2

individual trials can be send as follows:

TrialStart 1

TrialEnd