monitor_delay in behavior sync module

AllenInstitute / AllenSDK

code for reading and processing Allen Institute for Brain Science data

https://allensdk.readthedocs.io/en/latest/

Other

344 stars 150 forks source link

monitor_delay in behavior sync module #390

Open nicain opened 5 years ago

nicain commented 5 years ago

The current code is computing monitor_delay as approx 0.02204. Note that this is after fixing an apparent bug that set the delay to the default by erronously comparing delay instead of delay_std against DELAY_THRESHOLD (as was correctly implemented in stash.corp.alleninstitute.org/projects/ENG/repos/aibstim/browse/Analysis/OPTools_Nikon.py)

The delay value can also be computed as 0.01954 by using:

for interval_index, (ts, te) in enumerate(zip(stim_photodiode[:-1], stim_photodiode[1:])):
    if te-ts > .95:
        break
stim_photodiode = stim_photodiode[interval_index:]

approx_delay = stim_photodiode[0] - (sync_dataset.get_falling_edges('stim_vsync') / sample_freq)[0]

Getting a consistent and trusted value for monitor delay is critical and difficult

dyf commented 5 years ago

Need MPE to run an experiment to figure out why this delay is different on 2p5.

nicain commented 5 years ago

@dougollerenshaw

This looks relevant to the monitor_delay stuff we just discussed

dougollerenshaw commented 5 years ago

Here's the result of a display lag test on 2P6. if I use the falling edges of the vsyncs (which I believe to be the correct thing to do), I get a mean display lag of 23.7 ms.

If I use the rising edges of the vsyncs (which I believe to be incorrect), I get 35.1 ms:

dougollerenshaw commented 5 years ago

cc'ing @nickponvert.

wbwakeman commented 5 years ago

Doug has provided this notebook that includes a simple method for computing monitor delay per session.

https://nbviewer.jupyter.org/gist/dougollerenshaw/5f1ca1b60242cac7efb33bf9c4fa84a2

He will also provide a set of validation criteria that can be used to check that a per-session computed delay value is sensible.

wbwakeman commented 5 years ago

Validation criteria:

Every lag should be positive
The slope of a line fit through all of the lags should be close to 0 (if there’s a sudden change in the lag, it probably indicates a missed/extra edge in the vsync or photodiode signal)
There shouldn’t be any outliers (that would also indicate an edge detection issue)
The calculated lag should be consistent on a given rig across sessions (checking this assumes that you have the results of previous sessions accessible in LIMS, I’m assuming).

Also, note that the test in the gist above was on 2P6, not 2P5