- Wed Jul 23, 2008 3:26 am
#52422
Let me repeat myself here as it does not look like people have grasped the major issues with this sensor...
- No readout buffer
This means you can NOT halt the flow of data or the image would have been corrupted, thus there is no such function.
In RGB mode, the camera simply sends the data according to the master clock at some fractional rate determined by zoom setting and possibly some undocumented register.
In JPEG mode, the camera sends data at high rate, but intermittant. It does so "on-the-fly" as image data is dumped from the sensors, encoded and sent without being stored in advance.
- Poorly documented registers
All operations is done via I2C by writing or reading to any specified register in the camera. Theese control everything in camera including data output on/off but there is no way to pause the transmission if your controller can't keep up with the data flow.
I have not yet been able to get my cameras into fully auto mode on brightness, contrast, balance etc so images look awfull.
- Data-rate
At minimum clock input of 6 MHz, the internal PLL seems to generate around 8 MHz. To use Jpeg the internal PLL MUST be active. This means data will be sent out at 8 mbyte/second on the 8 bit paralell bus. There will be convenient or inconvenient pauses in the data flow (depending on your view) intermittantly as the camera encodes the data on the fly.
To handle the datastream you'd need to be able to receive the data, store it and increment the address inside your MCU before the next byte comes. You have to do this while keeping an eye on the VBLK and HBLK signals so as to know when there therre is an actual image and when there is data. Also, to read valid data, it has to be done synched to the DCLK signals clock flanks.
This really isn't a simple sensor to handle, and anyone thinking so will have a rough time. Either dedicated hardware, a very smart approach or a fast MCU is needed to get the job done.
Hope this is clear for everyone.
- No readout buffer
This means you can NOT halt the flow of data or the image would have been corrupted, thus there is no such function.
In RGB mode, the camera simply sends the data according to the master clock at some fractional rate determined by zoom setting and possibly some undocumented register.
In JPEG mode, the camera sends data at high rate, but intermittant. It does so "on-the-fly" as image data is dumped from the sensors, encoded and sent without being stored in advance.
- Poorly documented registers
All operations is done via I2C by writing or reading to any specified register in the camera. Theese control everything in camera including data output on/off but there is no way to pause the transmission if your controller can't keep up with the data flow.
I have not yet been able to get my cameras into fully auto mode on brightness, contrast, balance etc so images look awfull.
- Data-rate
At minimum clock input of 6 MHz, the internal PLL seems to generate around 8 MHz. To use Jpeg the internal PLL MUST be active. This means data will be sent out at 8 mbyte/second on the 8 bit paralell bus. There will be convenient or inconvenient pauses in the data flow (depending on your view) intermittantly as the camera encodes the data on the fly.
To handle the datastream you'd need to be able to receive the data, store it and increment the address inside your MCU before the next byte comes. You have to do this while keeping an eye on the VBLK and HBLK signals so as to know when there therre is an actual image and when there is data. Also, to read valid data, it has to be done synched to the DCLK signals clock flanks.
This really isn't a simple sensor to handle, and anyone thinking so will have a rough time. Either dedicated hardware, a very smart approach or a fast MCU is needed to get the job done.
Hope this is clear for everyone.
