DM365 IPNC + MT9P031 exposure time control

Akshay,

To do what you want to do, you'd need to change the value of NUM_STEPS from 3 to 1.

Xiangdong

Xiangdong,

I tried that but it doesn't make any difference. Basically, I am passing my exposure value as an argument to DRV_imgsSetEshutter(). This function then writes to the sensor register through its i2c API, I believe. NUM_STEPS doesn't come into the picture at this stage. 

-Akshay 

Xiangdong,

Also, the values being written to the SHUTTER_WIDTH_L register are changing every frame. The output, however, is not reflecting that.

-Akshay

Akshay,

I wonder how you modified the code. Did you modify TI2A_applySettings function to manually configure shutter speed by calling ALG_aewbSetSensorExposure() function? It sounds like you called the lower layer function to directly configure the sensor register. If so, where did you make the call?

Regards,

Xiangdong

Xiangdong,

Actually, at the moment, I'm not using AE at all. Eventually I hope to make my code work with the AE algorithm active. 

In the VIDEO_aewbApplyPrm() function, I'm setting (overwriting) prm.exposureTimeInUsec to two different values for alternate frames. Thus, the DRV_imgsSetEshutter() function gets called with a different exposure value for every frame. I've been toggling the exposure value between 1ms - 5ms or 5ms -20ms.

Looks like in the sensor datasheet there is a mention - in the 'Maintaining a Constant Frame Rate' section -

"The Shutter_Width_Lower and Shutter_Width_Upper fields may be written without causing a bubble in the output rate under certain circumstances. Because the shutter sequence for the next frame often is active during the output of the current frame, this would not be possible without special provisions in the hardware. Writes to these registers take effect two frames after the frame they are written."

So it would seem that what I'm up against is a sensor drawback. Do you have any idea as to the special hardware provisions mentioned above?

Regards,

Akshay

HI Xiangdong,

Did you get a chance to look into the feasibility of toggling exposure value for alternate frames? This feature is klnd of critical for us as this is the basis for our intended algorithm implementation. Appreciate your help in this regard.

Regards

Radhesh

Radhesh,

As I mentioned earlier, it is definitely possible if you change NUM_STEPS to 1 from DM36x perspective. My recommendation is for you to use the original IPNC 2A code and only changes NUM_STEPS to 1 and see what happened. You should be able to see the video flickers, as expected. Since you modified the original code, I have no way to know for sure that your modification is correct. So if you can start from the original source and do the suggested, then we can know for sure if it works or not.

Xiangdong

Xiangdong,

We will try this, but I am a bit skeptical. Because right now, we're manipulating the exposure time at the lowest level - from DRV_imgsSetEshutter(). In fact, if we do a DRV_imgsGetEShutter() right after this, we do see that the value of the 'Shutter Width Lower' register has changed, however that change is not reflected in the actual image.

The datasheet at one point mentions that if the register write is done in the blanking interval, then the new values will take effect on the successive frame. Is this what is being done in the current scheme? If not, how could we go about making the required modifications?

Regards,

Akshay 

Xiangdong,

Just to be clear, we're not aiming to have the AE adjust to different brightness in the space of one frame. What we are doing is trying to come up with a substitute for SALDRE which will take in two (consecutive) frames with different exposure times and process them (WDR, if you will). Regardless of AE, this scheme depends on the sensor being able to expose the scene for two different times successively. 

To test it out, we've tried to change the exposure time when the 2A thread goes for a DRV_imgsSetEshutter() every frame, but as you can see, we haven't been successful. 

For further details about what we're trying, you can also get in touch with Raghu Kudva, who is our point of contact here.

Thanks,

Akshay

Hi Xiangdong,

Any update on this front?

Regards,

Akshay