Converting RGB digital to RGB analog

[ex_mal]

Hey guys, i'm currently using a SONY CXA1645 chip to output video to the TV.

Currently trying to feed 24bit DIGITAL RGB data  to the RGB ANALOG input of CXA1645 chip. The CXA1645 datasheet shows that RGBin expects analog signals of 1Vpeak-to-peak, between 2V and 3V.

So here i am stuck. How to use a DAC do such conversion into analog signal that fluctuate from 2V and 3V.

Hope someone can help me out. Any suggestions?

[Aidan]

Can you give a bit more background on what you're trying to do, including the devices that you're trying to interface together?

[Guest]

ex_mal,

You've misinterpreted the datasheet. The RGB inputs to the CXA1645 must be capacitively coupled -- no DC offset is required.  

[ex_mal]

Can you give a bit more background on what you're trying to do, including the devices that you're trying to interface together?

OK...basically this is what i was trying to achieve. I am planning to output an image to the television. The image will be stored as RGB 16bit per pixel in an SRAM before sent to the video chip. I've already got the CXA1645 video chip to drive the image onto a composite video PAL tv.

I'm gonna use a PIC microcontroller to timely drive the image data from the SRAM to the RGB input of CXA1645 chip.

Clearly a DAC would be needed to interface between SRAM output of 16bit data (R-5bit G-6bit B-5bit) and the analog Rin Gin Bin of CXA1645 chip. So what i am thinking now, i need to use an 8bit DAC for each RGB and convert it to analog at the required voltage range specified by RGBin CXA1645.

2 things that bother me now
---------------------------------
-> What exactly is the RGBin requirement of CXA1645 (don't really understand the datasheet)
-> How to use the 8bit DAC to meet the requirement.

*Note:For clarity sake, I stated 24bit RGB data in my first post . Actually it's 16bit*

[Aidan]

From my understanding of the datasheet, the CXA1645 expects 1V p-p input on the RGB line inputs. As the inputs are capacitor coupled, you can't put a DC offset on them. Some manufacturers make triple DAC units, designed to handle video data. Most of them however, expect data in YCrCb format.

Most DACs are happy to produce whatever analog range you ask them to. Typically, all you need to do is set a reference voltage that typically determines either the 2/3 output   point or the full output point, depending on the DAC.

Worst case, you can use an octal buffer with an R/2R converter! Will the PIC you're planning on using be capable of doing what you're asking it to do? I don't know what resolutions you're trying to manage, nor what bandwidth you're expecting.

[ex_mal]

Most DACs are happy to produce whatever analog range you ask them to. Typically, all you need to do is set a reference voltage that typically determines either the 2/3 output   point or the full output point, depending on the DAC.

Thx for the reply. hmm sorry i don quite get what u mean by "2/3 output point or full output point"

Anyway yeah i guess i know what i should do now. Planning to get 3 octal DAC and bias the +ve reference voltage with 1V and -ve reference voltage with GND. Expecting the output to be 1Vpp ranging from 0V to 1V.

With regards to the PIC, yes it should be adequate. Gonna drop the resolution to 256x256.

By the way i've noticed a lot of people in this forum talking about CXA1645 chip. Most of them play with video format conversion between SCART,S-video,Composite and VGA. The input RGB data and sync only need to be manipulated. Have anyone tried generating the RGB and sync?...I'm trying to do that  B) hope it works.

[viletim!]

ex_mal,

The input to the video encoder (if you follow the app. circuit) is just a 1V peak to peak video signal. It passes through a capacitor and is blank level clamped at 2v. As it passed through a cap, the DC level doesn't matter you're signal can vary from 0-1v, 3-4v, -1-0v, whatever. As long as the level of white and level of black are a volt apart is doesn't matter.

A resolution of 256 lines is awful for TV. You can't fit that many visible lines in one frame @ 50Hz so you'll have to interlace and end up only using slightly more that half the available screen height. I'd suggest something like 230-240 lines, double that if interlacing, reduce by 20% if running at 60Hz.

You'll need fast DACs too...

[ex_mal]

The input to the video encoder (if you follow the app. circuit) is just a 1V peak to peak video signal. It passes through a capacitor and is blank level clamped at 2v. As it passed through a cap, the DC level doesn't matter you're signal can vary from 0-1v, 3-4v, -1-0v, whatever. As long as the level of white and level of black are a volt apart is doesn't matter.

A resolution of 256 lines is awful for TV. You can't fit that many visible lines in one frame @ 50Hz so you'll have to interlace and end up only using slightly more that half the available screen height. I'd suggest something like 230-240 lines, double that if interlacing, reduce by 20% if running at 60Hz.

You'll need fast DACs too...

Well about the 1Vpp video signal, thanks everyone for helping me see things better. I had a friend to explain it to me today already. Finally understood it.  

Viletim. Well about the 256 resolution is based solely the fact that i'm only able to get hold of an 8bit microcontroller. With 8bit i can only effectively 256 pixels in a line, or 256 lines of vertical resolution. I know an 8bit latch can be used to effectively achieve 16bit of addressing which can increase the resolution. Anyhow i've done much research,  if i do so, the transition from 256(0x00ff) to 257(0x0100) pixel will have an error pixel. For 0x00FF to go to 0x0100, two 8bit instruction is needed to change from 00FF->0000->0100  or  00FF->01FF->0100. Thus there will be a pixel of error. Unless i have a 16bit microcontroller to do 16bit change. But that'll be really expensive!

Anyhow, higher resolution requires higher processor speed. The current PIC i'm using is PIC18F452, the one of the fastest PIC available operating at max of 10 million instruction per sec (MIPS) or 40MHz. This would only be adequate for 256 pixel horizontally in 52us line image scan.

Well this is my final year project and there isn anytime left for any changes. Hope all the best for me. If anyone had tried generating RGB data and sync signal manually, please relate your experience   so that i can learn from people's mistake.