Camera module

Great project. I particularly liked the "problems encountered" section:

- RM

Interesting, but expected resolution and data throughputs. Some of the problems are lack of understanding of 4:2:2 data stream and colour frame sequencing. Without digging out the data sheet 17.7MHz clock suggest

I have seen PICs used in a similar manner, with next to no headroom for anything else.

Hmmm...I'm curious when you say "lack of understanding of 4:2:2 data stream and colour frame sequencing". Are you refering to the section of the AVRcam site where it talks about having trouble with the color format output from the camera? If so, I'm pretty sure this doesn't have anything to do with a lack of understanding of the 4:2:2 color format. I understand how this works, and, in playing around with other Omnivision camera modules (such as the OV7620), have seen it done properly. The oddest thing about the problem was that it came in sets of two: frame n and n+1 would produce expected RGB patterns, then frame n+2 and n+3 would produce "flipped" RGB patterns, the n+4 and n+5 would produce normal RGB patterns, etc. I am referring to the normal RGB pixel sequence when I say pattern here:

line x: ...R G R G R G R G... line x+1: ...G B G B G B G B...

being the sequence on frame n and n+1, but then getting:

line x: ...G R G R G R G R... line x+1: ...B G B G B G B G...

on line n+2 and line n+3, etc.

Perhaps there is something I just flat out missed, and this is commonplace, but I can't find reference to it anywhere on the datasheet. It is also possible that there is something else that I was doing wrong at the time, which made it appear as this funky problem. Not sure...I skinned the cat another way.

The OV6620 datasheet seems to have multiple confusing statements. For example, it states on the front sheet that the camera is progressive scan only, but there are multiple references to the camera working in an interlaced mode (though this mode can not be turned on or off through any of the regs...at least not that I can see).

Yup...the camera produces PAL video for viewing...

Really? I'd love to see a reference to that...do you have one?

Thanks, John

Yes it does in PAL format.

Your RGB is just a matrix formed from 4:2:2 YUV data, as from field to field as well as line to line UV order will change as part of the subcarrier phase change characteristics. There is an eight field colour sequence in PAL that determines that U moves by 135 degrees per field. Hence the Vaxis will swap as well.

Are you *really* sure that you are processing every line of every field? My impression of the write up was you grabbed as much as you could and then made up the picture from the next field as well.

It is part of decoding video in 4:2:2 format.

If I remember correctly the camera is capable of outputing colour bars by a pin setting or I2C control and I would use that as a reference to work out what is happening on a line by line basis and over at least eight fields.

The only real reference in the data sheet is to FREX (FRame EXposure) control linked to mechanical shutters. It is not the first confusing thing I have seen in Omnivision data sheets. Let alone contradictory or wrong.

So the timing will follow PAL timing standards even for colour sequencing. Actually I thought the output was VBS not CVBS (Luminance only not colour).

A good reference if you can get it is

Video Demystified - A handbook for the digital engineer

by Keith Jack of Brooktree (now Connexant and not interested in video)

Published by Hightext

ISBN 1-878707-09-4

I work with them most weeks, but the damn world of NDAs, means no online references except online Patents for 3D displays using headtrackers at the USPO. Needless to say I do not have the patent numbers to hand and the patents goes through overall techniques NOT specific chip implementation.