-
Notifications
You must be signed in to change notification settings - Fork 0
Protocols
Dev notes:
I think I'm just going to code a legacy adaptor rather than trying to integrate it into this system. Detect whether a protocol file is using the old or new syntax, then use that. OR just make a thing that converts old files to the new format.
NB default behaviour for tPre / tPost - Maybe by default throw an error if tPost is shorter than stim length and have some override behaviour?
A protocol file has 3 sections, separated by a ~ operator on a new line:
- General protocol parameters
- Trial information
- Stimulus definitions
You can add comments to a protocol file using the % operator. Comments in the trial information section will be displayed during the experiment.
The general section takes up the first non-comment line. It accepts the following arguments:
| Command | Explanation |
|---|---|
| nProtRunsX | number of times the protocol runs (including the first) - defaults to 1 |
| RandomiseX | how to randomise trials |
| dPauseX | time (seconds) between trials in the protocol |
| nTrialRunsX | (optional) change the default number of times each stimulus line is run for each protocol |
Each line in this block is a trial, which comprises a series of stimulus names. Stimulus names have three parts: the name, which maps directly to the protocol map; the optional sub-identifier, which can be used to isolate behaviour for devices of the same type; and the index, which is used to differentiate between stimuli for the same device over trials. Camera, CameraA, Camera1, and CameraA1 can all be used, with different outcomes in targeted devices. When no sub-identifier is provided, all active devices of the given type are targeted.
By default, all stimuli happen simultaneously, with the same start time. You can change this behaviour using some of the operators outlined below.
Settings for recording devices are defined in the protocol map, but can be redefined in this file if needed (e.g. you want a camera's acquisition to coincide with a flashing light). NB as far as I know DAQ cards can't be programmed to respond to inputs while generating buffered data. You can't write a light to respond to a camera's output line - you'll need a microcontroller or for both the camera and the light to be triggered by the DAQ
Once per trial, you can optionally define the following:
| Command | Explanation |
|---|---|
| nTrialRunsX | (optional) change the number of times this trial is run for each protocol |
In each block of stimuli, the following keywords can be defined exactly once:
• repDelXXXX - delay between repeats in ms. Default 0.
• startDelXXXX - start delay from stimulus t=0
• nStimsX (previously nRepX) - number of times the stimulus / stim block is run within a trial. Default 1.
-1 will make the stimulus repeat until the end of tPost.
#Legacy Protocol Files