Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

The network event is now implemented as a source. To use it, you'll need to add a merger module and link it to the main processing pipeline, preferably, before any other modules.

Peristimulus time histogram (PSTH) sink

The PSTH sink module has two main functions:

A. It 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.

B. It is used to save to disk all pipeline events that were generated after the source (i.e., network events, spikes, etc).

 

A. PSTH functionality

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

...


TrialStart 1

TrialEnd 2


Condition "GoLeft" will average both trials, condition "GoRight" won't have any information, since trial type 2 was never sent, condition "AllTrials" will also average both trials, but condition "GoRightCorrect" will only average the second trial.
TODO: add a simple C++ / Matlab program that show how to send trial information over zeromq.

 

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.
  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. int64, software timestamp
      3. 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. int16, number of points in each channel (typically 32+8).
      7. <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