Implement full trial logic workflow

[RoboDoig]

Experimental design_for Andrew_linear corridor.pdf

[EleonoraAmbrad]

comments after meeting on the 7.11: trial logic works really well for our purposes, we would however like to control the time of the trials and not only the amount of halts / gain modulation episodes presented.

[RoboDoig]

Going back over this and I think I've been confusing myself with the concept of a 'trial' in this context.

Would it be fair to say that desired behaviour is to set for each block (e.g. mismatch block type 1)

• The total time the block should run for
• The minimum running threshold before a halt
• The probability of giving a halt after the threshold is reached
• The minimum delay before giving this halt if chosen, + a randomly sampled delay
• The total time the halt should be applied (contingent on the animal still running)
• The gain applied on each halt (e.g. 0 for total halt)

From re-reading the description it seems like there are not really discrete trials, just the process of checking running threshold and deciding whether to halt or not repeated throughout the block. I guess my question is whether any parameters need to change on each halt decision / presentation or whether these parameters are the same throughout the block (with the obvious exception of the random delay added to the minimum delay).

In that case we could just set everything together once for each block, including visual stimulus type etc.

[EleonoraAmbrad]

yes, all you say here is correct, the parameters are set for each block. I think the word trial is a bit misleading, as each block will contain the set of parameters you listed and nothing should change except the random delay after the minimal delay

[RoboDoig]

Ok that's great thanks! I'm much clearer on this now.

[EleonoraAmbrad]

NPX data visualiser: following the meeting on the 2.2.24, we agreed with Gonçalo that the shader visualiser should be calibrated to our data.

In the Debug workflow, one of the NPX channels was streamed to the AnalogIO on the ONIX, then displayed on an oscilloscope. This works well on this workflow, but not in the "Insertion Workflow" that is used to record data at the moment (data displayed by the oscilloscope does not match voltage trace recorded by ONIX).

It would be great if the changes applied in the MinimalONIXDebug workflow were replicated in the Insertion Workflow

[RoboDoig]

NPX data visualiser: following the meeting on the 2.2.24, we agreed with Gonçalo that the shader visualiser should be calibrated to our data.

In the Debug workflow, one of the NPX channels was streamed to the AnalogIO on the ONIX, then displayed on an oscilloscope. This works well on this workflow, but not in the "Insertion Workflow" that is used to record data at the moment (data displayed by the oscilloscope does not match voltage trace recorded by ONIX).

It would be great if the changes applied in the MinimalONIXDebug workflow were replicated in the Insertion Workflow

This is added with PR #40

[RoboDoig]

Closing this issue with PR #44