Hi, I’m in a position where i need to be able to accurately and reliably set the exposure time in terms of milliseconds. I use the set_auto_exposure() function and it works in a way where a higher exposure_us gives a brighter image but the value doesn’t really makes sense when looking at the fps. For example in FHD an exposure time of 500 000 us should give me 2 fps, but i get 5… Increasing the exposure time further will also still make the image brighter so its not that it is saturated. This leads me to believe that the exposure time is not really 500 000 us. I looked through the code in the firmware as well, but couldn’t really see any problems in your exposure calculations. Do you know what the problem is?
Some of that code is user-contributed. But, seems to be correct. We don’t have a relationship with OmniVision where we can get FAE support to improve this. As of right now, the driver was written to the best information we could reverse engineer.
Note that you may wish to slow the PLL down via doing sensor._write_reg(0x3036, 0x40) to increase exposure. (SC_PLL_CONTRL2).
If you want reliable exposure, use the Global Shutter sensor. We have proper Datasheet access with Onsemi, so the driver for that is much more correct and was not reverse-engineered from minimal documentation.
I made a bug tracker for this. If you wish to send a PR and are able to fix it then it would be appreciated. I won’t be able to work on this though for a long time otherwise: OV5640 Exposure Calculation · Issue #2457 · openmv/openmv (github.com)
yeah, I have also needed to do my fair share of reverse engineering with the FREX trigger as well with this camera 
. Well, then at least I know that there is something wrong here, I’ll try to see whats wrong and I’ll get back here if I have solved it. Thanks for the help!
Hi! I have solved the issue and made a pull request. There were two errors done which is roughly explained in the description of the pull request, one was concerning the MIPI bit mode division and one was that the pll-predivider value was extracted incorrectly. After these two errors are corrected, the exposure time and fps match and the fps is never higher than what should be possible. Here is an example with exposure time of 100 000 us resulting in 10 fps in QVGA!
Ah, okay, great! Let me post this info on the pull request.