TVP5150AM1 Data stream and I2C instructions

The output from the TVP5150 conforms to the ITU656 digital video standard, and comprises of NTSC decoded luma and chroma samples in the YUV422 format. There is no quick or simple way to reduce the number of bits used since the synchronization codes require 8 bits to be unique from video data information.

The bandwidth of this digital output is is a 13.5MHz pixel rate which transposes to a data rate of 27MHz bytes/second which is about 250MBits/second.

The FTDI USB bridge is able to support up to 40MBytes/second, but you will most likely not be able to maintain that throughput. I don't know what realistic rate you will be able to achieve.

There is no way to reduce the video output rate from the TVP since it is a real time decoder.

BR,

Steve

Gotcha so, I mean 27x8 Mbps is about 216Mbps which is 27MBps, If the FTDI chip can handle 40MB/s steadily this wouldn't be a problem right? I'm trying to run this code on a c++ app I made, I really don't care about compression. I'm only concerned with getting the video in the computer you know? 

You need to talk with FTDI to fully understand the ACTUAL USABLE throughput you can realistically expect to achieve and sustain.

480Mbps assumes raw data, overhead, handshake, fully loaded throughput. In real life you never achieve that.

You also need to consider your software side since you will need to process the captured data at least to ensure alignment with the sync codes embedded in the video stream.

BR,

Steve

I have a question about those sync codes. If i choose embedded syncs, how dores that differ from discrete syncs? I'm assuming in both cases I have to use the Vsync and Hsync pins. What is the main difference on the outputs?

Embedded syncs embed synchronization information in the data stream. No need to look at the discrete H, V, AVID & F signals.

Discrete sync mode uses, well, discrete sync signals for H, V, AVID and F.

I suggest you review the ITU656 digital video standard for more informaiton.

BR,

Steve

Embedded syncs is the simplest from a hardware perspective since you only need 8 data signals plus clock but receiving software will need to search for the syncs in the input video stream to synchronize to it. You should only need to do this at the start of streaming though as long as there are no interruptions in the video stream.

If you find that you can't constantly stream through the FTDI chip then you will need to analyze the received video stream to constantly ensure you are synchronized in your interpretation of the video.

BR,

Steve

I have a digital scope, I'm assuming I could tell these embedded sync signals apart from the data stream by viewing it on the scope, right? By the way is there a way to know that I have programmed the registers correctly on the chip? I know for 8 bit 4:2:2 output the register config is pretty simple but I wanna check content in case debugging is necessary. 

A scope won't help but  a logic analyzer would.

Check the ITU656 spec for what to look for.

The only register you should really need to set is the output enable for the clock and data. Everything else should be automatic after that.

If this is what you want to check then you can look at the clock and each data signal on an oscilloscope, yes. If you want to loog at the video data stream then a logic analyzer is necessary.

BR,

Steve

I didn't know an external clock was necessary. But i see it on the datasheet now. I guess I can just get a crystal for it. But there is a clock output? Is this pin only used to sync each byte that comes out the TVP chip in my computer appplication? 

I suggest you talk with your adviser/professor regarding synchronous data transmissions. When sending parallel data there is pretty much always a requirement for a clock.

Looking at the FTDI device datasheet I don't think it will do what you need since it appears to need to be the clock master but the TVP must always be the clock master. The FTDI device does not appear to have a slave synchronous mode. I suggest talking with FTDI for more help though.

You will need some additional logic to synchronize the 2 devices together I think.

BR,

Steve

Oh Jesus, are you serious? yeah I guess I can ask if they have a chip that can do that. This sucks. I migth change cameras. This whole NTSC decoding seems tough. Maybe there are chips that go from YUV to USB interface? ever heard of anythign like this?

By the way, what happens if I don't clock this information with the clock output. In theory can't i just use any clock?

TI does not have any simple device to convert to USB.

What is the real problem you are trying to solve? Is there a reason you are not simply using a USB camera? OpenCV supports them directly.

BR,

Steve

You really need to talk with someone about synchronous data transfer. The clock is there for a reason. How do you expect the receiving device to know when to look at the data inputs to capture the data?

BR,

Steve

You think Taking that info and converting it to VGA would be a simpler process? does TI make ICs that I can implement this with?

What are you ACTUALLY trying to do?

Format conversion is never a simple task and there are always constraints, conditions, costs, complexity etc... that need to be traded off against what you are REALLY trying to achieve.

BR,

Steve

I think i just an epiphany. Follow me here:

Let's say I grab enough data for 1 frame, and process it on my piccolo. I forget about the next frame to minimize data rate and start grabbing the frame after that. In this making my picture 15 FPS ultimately. This way I can put the stuff trough my processor and onto the FTDI interface. I wanna transfer the video my surveillance camera captures into my computer. I have seen thsi done a billion times. Idk why im having trouble >__<

If you can capture the data stream without interruption with the Piccolo, and it has enough memory then it is a possibility.

Each video frame will need 675Kbytes for full color capture or 337.5K if you discard the color information.

The capture will probably need to use DMA and will need to be able to receive data clocked at 27MHz.

BR,

Steve

When the TVP chip mentions analog and digital grounds, how do I differentiaty between the two on my hardware?

In most systems you can simply connect them together.

Noise management is a completely different subject and not one answered quickly and easily.

In your application and setup just connect them together.

BR,

Steve

I guess what I'm confused about is: I have two pins for RX/TX for the ftdi chip and two RX/TX pins for my camera that I'm using. Do the registers know where to send the info? I can't seem to specifically tell it where to go. For example, If i receive info on pin 66 (rx of ftdi) i wanna send it out out pin 15 (tx to camera) and not pin 62 (tx back to ftdi). Or does this make TXBUF to go to all the TX pins enabled?

Grounds have nothing to do with TX and RX.

The FTDI device can emulate a serial port (using TX/RX).

You need to make sure your camera is a serial port interface too. You need to configure both the computer and camera to use the same speed etc...

Note, I don't think it is possible to use the FTDI chip in synchronous parallel mode and serial port emulation mode at the same time.

If the camera is serial port controlled then usually you connect TX from one device to RX on the other. Make sure voltage levels are the same though.

BR,

Steve

So the camera baud is 38400, same as my TI chip and the camera software (at the moment I'm trying to get JPEGs, i put the NTSC aside for a couple days). Let's say I have info on my RXBUF which is received from the camera software through the FTDI. When I go put that on my TXBUF to send to the camera it gives me a type definition error. I figured i could just move the RXBUF data into TXBUF but i guess it's not possible. Any idea why this can't be done?

No idea about the camera etc... sorry.

Well the problem is the buffer. How would i go about telling it where to send the received data on the chip?

No idea. This is a camera issue. Talk to the camera manufacturer.