This plugin has been deprecated.

Function

Aligns spikes and LFP to specific events, either sent through the Network Events source, or through hardware TTLs.

NOTE: The PSTH module will not work unless there is a Spike Sorter present in the same signal chain. This is something we're working to change, but as it stands, the PSTH module will only display data from electrodes that have been configured in the Spike Sorter!

This module provides a graphical display of the average response:

The module assumes that continuous channels connected are LFP channels. 

Best practice, is to split the broadband signal to two streams. Low pass one stream, high pass the other, pass that through spike sorter, then merge the two (such that LFP are the low count channels), and pass it to PSTH.

Neural data is averaged according to "Conditions". There are eight default conditions, each corresponding to a single trial type - a hardware TTL pulse.

Additional conditions can be defined using the network events module, which receives strings. See below:

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> Color <R G B> Visible <visibility> SpatialPosition <X Y> Group <group>
   
   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 smaller than 30,000. Values above 30,000 are reserved for TTL trials that are automatically generated.
   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.
   5. Color optional, and given by R,G,B, ranging between 0 and 255.
   6. Default visibility is optional. Visibility value is either 0 or 1, and will determine if this condition is visible by default, or whether the user needs to click on the GUI to make it appear.
   7. Conditions may have a optional 2D spatial position. This is useful when visual stimulation is delivered at a specific location on the monitor (i.e., saccade to a specific location trials).
   8. Conditions may be grouped together for easier visualization. For example, you might group a bunch of trials types with no stimulation together and compare them to trials that do get stimulation. Visualization in the future will be able to display them as two curves / rose plots / ... 
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.
9. DropOutcomes <trial outcome codes>
   1. This will indicate that all trials (regardless of their type) should be dropped and not analyzed if their outcome match the given list. Useful to drop trials in which the animal wasn't looking at the screen.
      
      

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 

An example how to send string messages to GUI from a c++ / matlab session will be available on github.

B. Save to disk functionality

In order to enable the save to disk option, you'll need to use the Record control module and enable the "Events saved by sink" option.

Events are saved in a new file format (0.3). Events can now have variable length, and are thus saved in the following format:

1. Event type (uint8) which can have one of the following types:
   1. SESSION (code 10)
      1. This will inform that a new recording session has started /stopped
   2. TTL (code 3)
      1. This will inform that a digital signal went up/down
   3. NETWORK (code 7)
      1. This will inform of a string message arrived via Ethernet
   4. SPIKE (code 4)
      1. This will inform of a detected spike
   5. TIMESTAMP (code 0)
      1. This will save a pair of software & hardware timestamps, to allow synchornization between software events and hardware events.
   6. EYE_POSITION (code 8)
      1. This will inform that a new eye position signal has arrived. 
2. Event size (uint16)
3. Event specific data (variable length)
   1. SESSION
      1. uint8, representing whether a session has started (value = 1) or stopped (value = 0)
      2. uint16, representing recording session number
      3. int64, representing a software timestamp
   2. TTL
      1. uint8, representing whether the signal went up (value = 1), or down (value = 0)
      2. uint16, representing the channel number that was raised/lowered.
      3. int64, software timestamp
      4. int64, hardware timestamp
   3. NETWORK
      1. <variable length>, representing the incoming message. length of the message is the event size - 8
      2. int64, software timestamp
   4. SPIKE
      1. int64, software timestamp
      2. int64, hardware timestamp
      3. int16, sorted unit ID number
      4. int16, electrode ID number
      5. int16, number of channels in electrode (typically, 1, 2, or 4)
      6. float x number of channels: channel gain 
      7. int16, number of points in each channel (typically 32+8).
      8. <variable length>, representing the spike wave form. actual size will depend on the previous two numbers.
   5. TIMESTAMP
      1. int64, software timestamp
      2. int64, hardware timestamp
   6. EYE_POSITION
      1. double, x position
      2. double, y position
      3. double, pupil diameter
      4. int64, software timestamp
      5. int64, hardware timestamp

Known bugs