corbennett
commented
2 years ago Here are some plots to show this phenomenon (from session 1086410738) . The first shows the interval between diode transitions. You can see that there is a long interval ( 1.068 seconds, or 68 ms longer than expected), but then this is followed by a short interval (0.984 seconds or 16 ms shorter than expected for 60 frames).
The vsync intervals for this period show a long interval ( ~76 ms, or 60 ms longer than expected), which is followed by a half-frame interval (~8 ms). This short frame interval is too fast for the monitor refresh rate, so it doesn't make much sense. My guess is that this frame doesn't in fact get drawn, which causes the next diode interval to be a frame short. Together, the delays of 60 ms from the long interval plus 8 ms from the skipped frame account for the 68 ms overshoot in the photodiode interval.
wbwakeman
https://github.com/AllenInstitute/ecephys_etl_pipelines/blob/176a302c1b35255f7e1b1a1ccae0ff2858ba15c5/src/ecephys_etl/modules/vbn_create_stimulus_table/create_stim_table.py#L830
Turns out camstim can 'skip' a frame. This leads to a diode interval that is about 1 frame short. The vsync for this frame still gets sent/registered in sync (so the total frames still add up), but the interval is much less than the expected interval (1/60). It seems that two frames basically get drawn at the same time.
The current compute_vbn_block_frame_times function only considers positive values for 'total_delay'. When a frame is skipped, total_delay is negative. To fix this, we just need to make the if statement capture non-zero delays (rather than just positive delays).