OPT8241: Frame rate versus size

• If a higher frame rate is selected, is there an effect on the data collected by the 8241 (e.g. less precise) or the processing of it within the 8241/9921 (e.g. less filtering) or it’s just that I need to have a faster interface to the 9921?

  A: higher frame rate reduces maximum allowable exposure time.  Reduced exposure time means less precise depth measurement.  Higher frame rate will means host receiving the data must be able to keep it, both computationally and I/O speed.

• Does a change in the number of sub-frames or quads change the frame size? If my understanding is correct, the number of quads determine a phase shift. So if 4 quads are selected instead of 2, either the frame size doubles or in the case of 2 quads each phase is done twice. It is also my understanding that the number of sub-frame determine the averaging being done. So if 2 sub-frames are selected instead of 1, I would assume that the frame size would double and I would need to double the frame rate if I wanted to get the data out in the same time (thus my first question).

  A: Changing sub-frame may and quads may reduce output frame rate, but does not change frame size.  Sub-frame averaging is done internal to OPT9221.

• If only a subset of the array is selected, are only the data related to that subset sent or the frame contains the full array in any case? If the full array is sent, what are the advantages of selecting a subset of the array (e.g. higher frame rate with no degradation of collected TOF data)

A: if you are referring to ROI, only ROI will be outputted as a frame. In this case the frame size will change, and higher frame rate is possible, but only from output throughput perspective, not data collection.

Point 1. I should have mentioned that I noticed that when the frame rate is changed in the 3D Estimator, only the Illum Ouput power is affected. So if the frame rate is set higher but the Illum Output power is increased to compensate, are there any side effects on the data collected by the 8241 or the processing of it?

Point 2. In the OPT9221 datasheet equation (3) paragraph 7.3.3.2 determines the pix_cnt_max defined as the number of system clock cycles in one frame which is based on the system clock frequency, frame rate, quad count and sub-frame count. My guess is that each pixel uses one clock cycle from the pix_cnt_max and the remainder are dead time. However equation (2) indicates the frame dead time (lumped dead time set to 1) is based on sub-frame count, quad count, pix_cnt_max, integration duty cycle, sensor reset time and readout time. Since sub-frame count is fixed, quad count is fixed, sensor reset time is fixed (768 clock cycles), and readout time is fixed (based on a fixed number (401) and number of columns and rows), and you indicate the frame size doesn't change, it leaves integration duty cycle or frame rate as variables that are modified to balance the equations. Therefore if the integration duty cycle is modified, the frame rate going to change. Is this correct?

Point 3. Yes I was referring to ROI. What do you mean by "not data collection"? How can the output frame rate be different than the data collecting frame rate (which I assume is given by equation (3))?

Additional question. What is the latency between the data collected by the 8241 and the output of the 9221? For example, assume an object instantaneously appears in the field of view. What is the time delay when the 9221 indicates so in the output data.

Point 1. I should have mentioned that I noticed that when the frame rate is changed in the 3D Estimator, only the Illum Ouput power is affected. So if the frame rate is set higher but the Illum Output power is increased to compensate, are there any side effects on the data collected by the 8241 or the processing of it?

>> When frame rate increase, the equivalent integration time is reduced, and less light gathered. This will leads to reduced depth accuracy. To keep the same specified depth accuracy, illumination power is increased to compensate. In practice, increasing illumination power will leads to a phase shift, and offset calibration will need to be performed.

Point 2. In the OPT9221 datasheet equation (3) paragraph 7.3.3.2 determines the pix_cnt_max defined as the number of system clock cycles in one frame which is based on the system clock frequency, frame rate, quad count and sub-frame count. My guess is that each pixel uses one clock cycle from the pix_cnt_max and the remainder are dead time. However equation (2) indicates the frame dead time (lumped dead time set to 1) is based on sub-frame count, quad count, pix_cnt_max, integration duty cycle, sensor reset time and readout time. Since sub-frame count is fixed, quad count is fixed, sensor reset time is fixed (768 clock cycles), and readout time is fixed (based on a fixed number (401) and number of columns and rows), and you indicate the frame size doesn't change, it leaves integration duty cycle or frame rate as variables that are modified to balance the equations. Therefore if the integration duty cycle is modified, the frame rate going to change. Is this correct?

>> 'pix_cnt_max' = quad time.
>> Integration duty cycle is just a percentage of 'pix_cnt_max'
>> At a given frame rate, number of sub-frames, and number of quads per sub-frame, 'pix_cnt_max' is fixed. This also dictates the maximum integration time. Higher the frame rate, lower the maximum integration time. Any integration time lower than the max, the balanced is buffered in 'dead time'.

Point 3. Yes I was referring to ROI. What do you mean by "not data collection"? How can the output frame rate be different than the data collecting frame rate (which I assume is given by equation (3))?

>> Data collection timing is separated from readout timing with the DDR2 buffer. But sensor readout time will reduce if ROI is reduced, and therefore increases max frame rate.

Additional question. What is the latency between the data collected by the 8241 and the output of the 9221? For example, assume an object instantaneously appears in the field of view. What is the time delay when the 9221 indicates so in the output data.

>> 1 frame delay