JRobot

Hello
First off, I must say I'm very impressed by your AVRcam. I think it's incredible how you were able to squeeze all those algorithms into a mega8.

Now for my question. I read somewhere that you used the same crystal for the microcontroller and camera module to gain higher transfer rates. How exactly does that work? And why does it lead to higher transfer rates?

i believe PCLK decides transfer rate..hence if higher clock rate,higher PCLK and hence higher transfer rate

But why does using the _SAME_ crystal give a higher transfer rate?

It all comes down to the processing that needs to be done with the data coming from the camera. A typical loop processing loop would look like the following (executing on the mega8):

start loop
wait for PCLK to go high
sample Y data bus for a red value
sample UV data bus for a green value
wait for PCLK to go low
wait for PCLK to go high
sample UV data bus for a blue value
perform some processing on the sampled data (in the case of the AVRcam, decide if the RGB value is in the color map, and run-length compress the data in the current line)
end loop

All of this processing needs to be done in around 16 clock cycles to keep up with the full-speed image stream from the OV6620. However, just the loop to monitor when PCLK changes state, and loop back to check again if it HAS NOT changed state, can maximally take 3 or 4 clock cycles. As you can see, this would simply eat up too much time.

So the trick here is to use the same clock source for both the mega8 and the OV6620. Thus, I no longer need to sample the PCLK line in between pixel data; I just need to synch up once with it at the beginning of each line. Once the timing is set, I can guarantee that, say, every 6 clock cycles, the data on the data bus will have changed values, and will be ready for sampling, thus eliminating all those cycles checking the state of PCLK. If different, un-synchronized clock rates were used for the mega8 and the OV6620, this wouldn't be possible.

Make sense?

Hmm, yes, makes sense But why do you need to syncrhonise at the beginning of each line then? Doesn't it always take just as long between each line?

And another question. If you would make your AVRcam again, would you use the same camera module?

Can I change C3088 with C3188?
I only have C3188..
So, can I change C3088 with my C3188?
Please..
Need help

No, the AVRcam only works with the C3088 module (which uses the OV6620). Search the forums for other threads discussing the C3188 module.

johno wrote:No, the AVRcam only works with the C3088 module (which uses the OV6620). Search the forums for other threads discussing the C3188 module.

Therefore, do you know how to use my C3188 module?

thanks before...

I would also like to know which parts of the system have to be modified in order to work with another camera module.

And also if my camera does not work with QCIF resolution, is it possibile to use QVGA resolution by modifying the image processing code?

As I know VT6620 is an old model and will be faded out very soon. I can't find this model from the OmniVision web site. I think there is a need to make it compatiable to the new components which provide better quality video source so as to improve the tracking result.

Thank you very much for your help in advance!

Alex

I agree that the OV6620 is an older module, but it is one of the only modules that can be purchased already mounted on a PCB, with a lens, and with all i/o brought out to 0.1" headers. And did I mention that the datasheet is freely available? All of this makes working with the module fairly straightforward.

I would love it if someone took on the project to support another more current camera module. The module would have to minimally support QCIF data, since I'm pretty sure this is the fastest stream that a small micro can keep up with in real time. It would also have to bring out a clock signal to allow the external micro to synch up with it (like the AVRcam does). Of course, it is also possible to drop another micro into the system instead of an AVR...I've thought about doing similar things with an ARM7TDMI (specifically, the LPC2103 ARM from Phillips), but have yet to find the time to make it happen. I would certainly encourage anyone interested to give it a shot. I'd be available for answering questions if needed.