Frame Interval Timing Explained¶

This is an excerpt from an email describing the Image Interval parameter that may not be clear in the MityCCD API descriptions.

The MityCCD imaging cycle involves 3 parts: exposure, readout, and data transfer to the PC. We've designed the firmware in the camera to support transferring the data to the PC asynchronously with the CCD exposure and readout. For continuous imaging, the link transfer time cannot exceed the sum of the exposure and readout time, or else the camera will run out of buffering space and dropped frames will occur. The ascii art below illustrates that, I hope:

       <--- exposure 1 ---><--- CCD readout 1 -><--- exposure 2 ---><--CCD readout 2-><--- exposure 3 ---><- CCD readout 3 --->
                                                <------ maximum link transfer to PC 1-><---- max link transfer to PC 2    ---->
shutter_____________________                    ____________________                  ____________________
  pin |                   |____________________|                   |-----------------                    |____________________
      <-------IMAGE INTERVAL -----------------><------IMAGE INTERVAL ----------------><------IMAGE INTERVAL ----------------->

If you use a zero Image Interval, then in a multi-frame capture the next frame starts as soon as the readout of the previous frame completes. This usually results in very low jitter in exposures unless you are approaching 100% utilization of the link bandwidth. Any hiccups in communications (retransmits in either ethernet or USB due to dropped packets or a busy stack on the PC is typically the culprit) may result in a stall of the next image cycle until there is room available to store the CCD data in camera memory for transmission to the PC. If you aren't using an external shutter, this will result in a variance in exposure time. If you set the Image Interval to a non-zero value, then you can create margin in the link transfer times and ensure no variance in frame timing (a delay is added after readout to pad out to the specified interval). The trade is slightly lower maximum continuous framerate for reduced likelihood of jitter in the exposure period.

For binned readout and/or high speed USB, the link transfer time is quite short, so the dominating limit to the fastest possible image interval time is the exposure and CCD readout time.... UNTIL you get to the point where you are trying to push to 1 ms exposure periods with a high amount of binning (low exposure + low readout time). Unless you are capturing large / continuous sets of very short exposures (e.g., continuous frames at 1 ms exposure intervals), you shouldn't need to use the Image Interval parameter.

In the above drawing, the shutter is just the GPIO pin output. If no external shuttering is used, then you start exposing your next frame immediately after readout completes, and increasing the Image Interval is the same as increasing the effective exposure time (the readout time is fixed). If you do have a shutter, however, then increasing the image interval only impacts the frame rate and not the exposure time (though arguably you will get a bit more dark current in each frame).

This timing is a little complex, and really was put in the interface to handle a couple of boundary use cases we've run into. The most common is continuous captures at maximum possible framerate, using minimal exposure times, and requiring precise background subtraction from frame to frame. This scenario typically involves some sort of transient analysis / detection.