Video Scan Conversion Rate - Camera Input to DVI Display Output

Is the line in your 640x480 source signal when the camera moves?

Are you moving the camera with a motor? Does the line come from cross talk from the motor? Are your cables shielded? Try moving the camera manually (you may need to disconnect the motor), is the line still there? If no, you better find a person who is good at EMI/Cross talk issues

Are you moving the camera manually? Do the vents get blocked and the camera control unit heat ups (happened to me once - someone set paper on top of the camera control unit)?

Are you synchronizing the signals that handshake the buffer trade-off since the cross clock domains?

Cheers, Jim

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto: snipped-for-privacy@SynthWorks.com SynthWorks Design Inc.

1-503-590-4787

Expert VHDL Tra> Hello all.

Hi Scott, I think the problem is that when you swap RAM banks, your camera can have written a partial frame to the write memory. This is fine when the camera's still, because the data are identical to the last frame, but when the camera's moving it's gonna go wrong and leave artifacts. You'll have half of an old frame with half of a new frame in the buffer. Try this. As the write frame rate is > 2x the read frame rate, when you swap read banks, wait for the start of the next write frame then write that into the write buffer. Then stop writing until the frame read cycle is complete. Then swap banks and start all over again. HTH, Syms.

Another way could be to construct a big frame fifo using the 2x2M srams you have. Since you cross clock boundaries, you need to construct an async. fifo.

Hint to fifo construction:

1. ping-pong between two srams
2. an ififo(xilinx internal) for camera input
3. an ofifo(xilinx internal) for dvi output
4. counters on each end to keep tracking pixel flows

hi scott, I assume your camera output is 125 fps, non interlace? At the output DVI requires 60 fps, that mean you are dropping 65 frames per second. As other mentioned, you need to make sure to swap the buffers in sync with the camera vsync that makes image integrity. Since you are vertically down-scanning, 2 frame buffers is enough, otherwise you may need more than 2 buffers or the dualport rams. One thing I doubt about 125 frames/s camera non interlace?

scott, input 125 fps, output 60fps.

2 frames sram. write one, read other. write pointer faster read pointer about 2x. need to drop 65 frames per second. sram is not dual port. can't write while reading. got it?

scott, input 125 fps, output 60fps.

2 frames sram. write one, read other. read pointer faster write pointer about 2x. need to drop 65 frames per second. sram is not dual port. can't write while reading. got it?

scott, input 125 fps, output 60fps.

2 frames sram. write one, read other. write pointer faster read pointer about 2x. need to drop 65 frames per second. sram is not dual port. can't write while reading. got it?

Others have already described methods to ensure that your read and write pointers don't cross.

I have a couple of additional comments though.

I don't understand why you get a white line when you pan the camera. You should get a horizontal line of horizontal dislocation that moves up or down the screen, but there should not be anything there that is not in the original image. If there is a white line, for example when the image is dark, then you have something else going wrong.

The fact the camera is running at 125 Hz suggests someone was concerned about motion. Going down to 60 Hz is going to do nasty stuff to your motion. Most times you will be dropping one input frame, but sometimes you will be dropping two in a row.

If the monitor will handle 62.5 Hz, you will get better motion if you lock the output frame rate to the input. Of course, if the monitor also has a frame buffer in it, that defeats the purpose.

If I was you I would first make a free-running 62.5 Hz output raster, and generate a video pattern with horizontally moving vertical bars. If this displays without tearing on your monitor, then you can lock the output raster to the input and do the scan conversion. (This also makes your double buffering easier).

Hi,Scott, I'm planning a new project related to yours, though I need both DVI input and output, may I know the source of FPGA development board that you are using ? where you bought this board from ? thanks, Julian