Miniscope DAQ TTLs don't match amount of recorded frames

[ChucklesOnGitHub]

This is a user issue that I've recreated and was discussing with Aarón to figure out where the mismatch is coming from.

This is acquiring from the MiniCam in the Bonsai package, set at 47FPS and sending the MiniscopeDAQ TTL (Sync Out) to ch1 on the OE Acquisition Board digital input.

In example Mateus:

• software timestamps and frames recorded in video are 1428
• TTL toggles in acquistion board are 1449
• frameID has a difference of 1439 between the first and the last but has repetitions and skips

In example test1 (Ceci):

• software timestamps and frames recorded in video are 2803
• TTL toggles in acquistion board are 2814
• frameID has a difference of 2805 between the first and the last but has repetitions and skips

Here are the files: https://drive.google.com/drive/folders/1HH4wa-SvIkGSZJ0daf12GQvjlD4wXpxj?usp=sharing
I've done some preliminary analysis here, but this needs work to figure out a better way to look at the deviations:
https://colab.research.google.com/drive/19WtO5Xj4IGzSBvJb_OdGDAWXU3U2DiTp?usp=sharing

The goal is to understand what frame happened when in the ephys.

[aacuevas]

What's the time difference between the first and last ttl and the first and last timestamped frame? How many frames fit in that time?

[ChucklesOnGitHub]

In example Mateus:

• TTL times: 162.266167-131.416267 = 30.8499 sec -> 1449 frames expected at 47 FPS
• soft_times: 39.913690-9.261555 = 30.652135 sec -> 1440 frames expected at 47 FPS

In example test1 (Ceci):

• TTL times: 72.158900-12.227167 = 59.931733 sec -> 2816 frames expected at 47 FPS
• soft_times: 103.0196736-43.256448 = 59.7632256 sec -> 2808 frames expected at 47 FPS

[ChucklesOnGitHub]

Typically I would look at this by checking the holes in the software timetamps. In Mateus' example, this gives 8 holes in the timestamps and based on the elapsed time, we can estimate 14 frames lost.

And then since there is a mismatch at the end possibly because the software takes some time in telling the hardware to stop acquiring so the TTLs keep streaming for about 9 TTLs (assuming the alignment was correct - first TTL matching first frame acquired):

This would roughly match the 21 frame mismatch between the TTLs and timestamps. I guess a way to control this would be to use the trigger function. Maybe that is what is missing here to provide precision. (And, separatey, figure out why the frameID is being reported weirdly)