2
\$\begingroup\$

I have recently started a project where I want to use this small camera and and have it relay the live video to a very small color LCD, like this one through an Arduino.

Unfortunately the camera has a NTSC output and the LCD has a SPI input, is there any way I can get the footage from the camera to display on the LCD or will I have to use a different screen?

\$\endgroup\$
  • 1
    \$\begingroup\$ Did you follow the 2nd link in the description of the camera, where it says "We have a very detailed tutorial .." ? Seems like your question might be addressed quite well by what I just looked at there. \$\endgroup\$ – JustJeff Apr 3 '12 at 2:28
  • \$\begingroup\$ @JustJeff The tutorial shows how to connect it directly to a display that has an RCA jack, the small LCD I wan't to use doesn't have one. \$\endgroup\$ – johnny1bucket Apr 4 '12 at 12:21
4
\$\begingroup\$

Well you would need to digitize the video, extract luminance, chrominance & sync information, downscale from 525 lines to 128 lines and output the data over SPI in real time. This sounds like a non-starter to me.

It would be easier to use the JPEG digital output from the camera and decompress this, since the resolution is compatible with the screen (160 X 120 vs. 160 X 128) although you still wouldn't get real-time video.

\$\endgroup\$
  • 1
    \$\begingroup\$ @clabacchio - The camera vendor's web page states: "...it outputs NTSC video and can take snapshots of that video and transmit them over the TTL serial link". I take this to mean that it outputs both analogue and digital. If the output is purely TTL data containing JPEG images, why do they mention NTSC at all? \$\endgroup\$ – MikeJ-UK Apr 3 '12 at 7:59
  • \$\begingroup\$ @clabacchio - The OP's camera link is on makershed.com. Look at their large image of the camera. Pin 6 is marked 'CVB' - composite video. Another image shows this connected to a yellow RCA jack. \$\endgroup\$ – MikeJ-UK Apr 4 '12 at 12:34
  • 1
    \$\begingroup\$ Wait, wait, sorry. The serial interface allows only the snapshot downloading, you're right. \$\endgroup\$ – clabacchio Apr 4 '12 at 12:41
1
\$\begingroup\$

EDIT: I was wrong about the video through the TTL interface: you can take snapshot and send them through the UART, but for the video the only way is the analog output. So for it you will need a fast ADC and digital manipulation, and it won't be so easy.

Though, you can use it to send pictures with a low framerate, like "real-time" weather monitoring webcams.

What you need to define is the encoding of the image from the webcam (bit depth and framerate) and eventually write the code to convert it in a format compatible with the display (it has different options, read the datasheet).

It may be possible also to forward directly the image from the TTL input to the SPI input without processing, but you still have to handle the communication and it will be easier if your uC has both the UART and SPI interfaces.

So it's not impossible, but requires some work.

\$\endgroup\$
  • \$\begingroup\$ Do you happen to know of a library that can process and convert the video? \$\endgroup\$ – johnny1bucket Apr 2 '12 at 15:23
  • \$\begingroup\$ @johnny1bucket no, never done it :) but you can look at the camera and display drivers first, and then try to google it \$\endgroup\$ – clabacchio Apr 2 '12 at 15:25
  • \$\begingroup\$ @johnny1bucket - I'm not going to chase it further, but if you look at the end of the tutorial (see link in camera description, after OP's link), there are couple of likely looking candidates. \$\endgroup\$ – JustJeff Apr 3 '12 at 2:33
1
\$\begingroup\$

Capturing a black and white NTSC video signal isn't overly difficult, especially if you're not too worried about resolution or frame rate. There was a video capture gizmo that plugged into the printer port of an Amiga 1000, for example. No fancy zillion-megahertz microcontrollers back then--just some discrete logic, a sample-and-hold, and a not-terribly-fast ADC which IIRC captured 5-bit data at 15KHz (about 5-seconds per frame, black and white). I would expect that you would want to, and could, capture monochrome data faster than that with a decent microcontroller. If you want to capture a crude 128x100 image at 30fps, you'd probably need to capture about 0.8 megapixels/second (capture 1/4 of the pixels horizontally on each scan line, on two fields).

Capturing color from a "general" NTSC video source is much harder, since there's no fixed relationship between chroma phase and horizontal position. Many video sources, however, including cameras, computers, and DVD players do have a fixed relationship between chroma and horizontal position (there is a standard for what the relationship should be for "perfect" video, but not all devices comply; most devices other than VCRs will have a consistent relationship, but they may or may not match the standard). If you can design around a particular known input source, and can accurately measure timings with regard to horizontal sync (timing precision will be much more important than with monochrome video) color sampling may be practical.

Without knowing what you're wanting to do, I can't say what the best approach would be. You might be best off using an LCD display with a composite video input and overlaying video on that. Color overlay is generally a pain, though if you want a horizontal "split screen" it might be possible to cheat (sets with analog color circuitry would not work well if one part of the screen used different color phase from another part, but LCD screens with a digital front end might not mind; if you generated your own chroma on lines where you wanted to display your own color, and let the camera chroma through on others, I'm not sure what would happen).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.