Digital processing of analog TV broadcast

Hello,

I'm current designing a device which will digitally convert an analog (NTSC) signal to RGB (for use in VGA). I have some questions at the bottom of this post. The system design consists of:

- 50 MHz FPGA

- 50 MSPS 10-bit ADC with video clamping

- Matching DAC

- Baseband NTSC composite video source

- VGA monitor

The FPGA includes the following sub-blocks

- Polyphase resampler - converts sampled data to 4 * color subcarrier frequency (I think this is the correct term, but I'm not sure. I'm basically interpolating and then decimating by integer factors)

- Low pass filters - I plan on using windowed sinc (FIR) filters for everything, unless there is a compelling reason not to

- Numerically controlled oscillator - I will store a table with a quarter cycle of a sinusoid, and use trig properties to calculate the rest. The index will be N-bits long, and the table will have significantly less than 2^N entries. Only the most significant bits of the index will be used, and the lower bits will actually be used for interpolation (this idea isn't originally mine).

- Digital PLL or digital Costas loop - Any advice as to which to use? Needed to lock onto color burst to generate reference color subcarrier. I plan on using TWO seperate PLL's, since the chroma subcarrier is phase-inverted on each line. Each PLL will be updated alternately, every other color burst. This will minimize tracking requirements, I think.

- 2D adaptive comb filter - takes advantage of the fact that the chroma subcarrier is phase inverted on each sucessive line to allow good seperation of luminance and chrominance. Since the data has been resampled to 4 * Fsc, there will be a constant number of samples per line, and the pixels will "line up", making the comb filter easier to implement.

- QAM demodulator - Uses the PLL or Costas loop reference color subcarrier to demodulate the chroma signal. Needs only multiplier(s) and low pass filters. I'm going to use narrowband color and demodulate I and Q with 0.5 MHz bandwidth each.

- Sync detector

- Matrix to convert from (Y, I, V) to (R, G, B)

- Video buffer at 640x480. Each time a field is digitized, every other line of the buffer will be updated. The VGA output will run at 60 Hz, giving the same interlaced appearance as a regular TV. There may be better ways to do this, but this is simple and easy. I'd rather not deal with motion compensation.

- VGA output generator - Reads video buffer, generates RGB, sync pulses, etc

QUESTIONS:

- I have found a few ADC's that are up to the task, but does anyone know of one that is particularly easy for prototyping? I've never done any surface mount soldering before. I did read about a way to use solder paste and reflow in a toaster oven, but it'll probably be trickier than it sounds. I don't suppose anyone makes a high speed video flash-ADC in a DIP format? :-)

- Low pass filters are used in a few places above (in the Costas loop, in the chroma demodulator, and in the interpolation part of the polyphase resampler). I planned on using windowed sinc filters everywhere, just because that's what I'm most comfortable with. Can anyone give me a reason not to? And if so, what would be recommended?

- If anyone is willing to go over polyphase resampling or digital PLL's / Costas loops, let me know. I'll post my current understanding (courtesy of google), and see if it is flawed. I think I get it, but... this is all fairly new to me. The best resources I found were from a place called "ChipCenter", but there wasn't a whole lot of other material that was helpful. Lots of IC datasheet results, which made it hard to find info on the theory.

- Any other pointers, or things to watch out for? A lot of this is fairly new to me, though I can at least "hold my own" on the FPGA side of things.

Thanks in advance !

Sean

Reply to
sp_mclaugh
Loading thread data ...

On a sunny day (26 Nov 2006 20:44:23 -0800) it happened sp snipped-for-privacy@yahoo.com wrote in :

Sure, TDA8708A. As to the rest of the project, you probably know Philips (or whatever name they use these days) has chips that do all that color digitising and demodulation, but not in DIP I think.

I do not have a lot of time now, I will read you posting again later.

Reply to
Jan Panteltje

Wow, I was actually being sarcastic, but that just made my life easier! I was just about to go pick out a nice new toaster oven...

True, though part of the main theme of this project is keeping component count down. I'd like to do everything on the FPGA (except I can't get around an external ADC). I have no plans to commercialize this project, though I will likely use it myself. I see this becoming one of those projects that I add on to from time-to-time to use as a testbed for new designs (perhaps I'll decide to test out a 3d adaptive comb filter next year, or direct IF sampling, etc).

Thanks, this first post has been a big help already w/ the chip recommendation !

Sean

Reply to
sp_mclaugh

FPGA board?

mm

OK

I multiplied the 50MHz FPGA clock to 200MHz (DCM), this gives quadrature signals at 200MHz....

I found that tricky, so for PAL I used an external Xtal 4.43 (or 8.86 MHz). I found that tricky, so for PAL I used an external Xtal 4.43 (or 8.86 MHz). :-)

This will depend on how accurate you can get subcarrier lock. With a 50 MHz clock you have a tick every 20 nS, for NTSC period time is some 300 ns? (an estimate, I am in PAL land) so and you want to sample

2 times in a period, your sample target:

I Q

. * . . .* * . . * . * . . _____ *______ . ____________________ . _______________________ * . . . . .

300ns

| | | sample Q sample Q | | | | sample I | sample I |

------> 75ns | -----> 225ns | | |

------------------> 150ns ----> 300ns

Using the 50 MHz clock with 20 ns resolution will never give you the exact sample point. With a 200 MHz clock you have 5 ns resolution (should be enough), with a 200 MHz 4 phase clock 1.25 ns resolution.

This right? This is why I went to 200 MHz. And a few other reasons too.

That is the easy part, although many standards exist :-) (ask me if you want to know more, I have tried some...).

Maybe there is no need for a full frame store, unless you want to make a time base corrector that can handle asyc input sources, and sync these to some reference. I did the line doubler (this is called a line doubler) by simply storing a line in FPGA block RAM, those are dual port RAMS, and reading it out at double speed. Thats is all. So each line is repeated twice. That way 15625 Hz becomes 31250 Hz, nice for a VGA monitor, the 50 (or 60 Hz in your case) stays the same. You do not even have to sync that clock.

I used a 2x PLL on H to get H sync for the VGA. Watch out for jitter and lock in range, especially with VHS as input.

Long time ago I tried all this.... Digilentinc digilab2 Spartan2. Hope I remembered it right.

Analog is better? Looks like it! LOL

Reply to
panteltje

Is there any reason you are re-inventing the wheel?

Averlogic AL250

  • Philips SAA7111 (or is that NXP?)

Total cost about 30$.

Reply to
a7yvm109gf5d1

I second this. Unless you are doing some additional processings, which would require external memories anyway.

Add $10 more for a graphic chip (VGA output).

Reply to
linnix

What are you talking about? That's what the AL250 does...

Reply to
a7yvm109gf5d1

Without looking at the spec, I though that's a micro. But in this case, what do you need the SAA7111 for?

Reply to
linnix

How about looking at the specs?

RTFDS.

Reply to
a7yvm109gf5d1

I'm using a Xilinx Spartan 3 running on a Digilent starter board. At this point, the ADC and DAC will probably be mounted on a seperate breadboard (or PCB, if I feel like outsourcing it).

Ha, that's what I said... I've never done one of these before. The name sounds intimidating, but I don't think it'll be too bad.

I've never used the DCM before, but I just downloaded a Xilinx appnote, which I'm reading now.

I'm probably going to do some Matlab simulation first, to make sure I get it right. This is mostly a learning project, so I'm going to try to do it all on the FPGA (just out of stubbornness).

The NTSC subcarrier frequency is 3.579545 MHz, so 279.4 ns (pretty close). I was going to just sample as fast as I can (every 20 ns), and use the polyphase resampler (upconvert, interpolate w/ FIR filter, and decimate). Then demodulate by using two multipliers (mult by sin/cos) and two low-pass filters to remove the double-freqency terms.

Hmm, I think you're using a different QAM demodulation method than I am. I'll have to break out my book and get back to you.

Yes, this part will be a relief. Oops, I think I meant to write (Y, I, Q).

You're completely right. I just happened to already have a Xilinx module which reads from a frame store and handles the VGA generation. If I didn't already have this made and working, I would do things differently.

I was going to do this, but I can't remember why I ended up deciding not to... I will consider doing that rather than updating every other line. Either way should be about the same amount of work, I think.

That is definitely convenient. Again though, I'm just viewing the VGA module as a "black box" - I just write to the frame buffer and forget about it. Of course, I still do have to have a 2x synchronization between the composite input and VGA output, or weird video will occur during motion. I might just accept this for now, and make a tunable VGA module down the line.

Yep, I'm using nearly the same thing (Digilent Spartan 3).

Haha, I think you're probably right. But once I get this basic version working, there is a whole lot of room for improvement, which could surpass analog (ie, a 3d adaptive comb filter isn't possible with analog - or surely isn't practical).

Thanks for the help, I'll try to understand your IQ demodulation and how to use Xilinx's DCM. However, since I'm sampling way faster than the Nyquist rate (20ns vs 279ns), shouldn't my method work (synchronous demodulation)? Like I said, I'm new to this.

Reply to
sp_mclaugh

Yes, I am do Also, I do plan on adding to this basic functionality later (possibly:

3d adaptive comb filter, direct IF sampling, various digitally encoded output for video capture, etc)
Reply to
sp_mclaugh

On a sunny day (27 Nov 2006 14:39:50 -0800) it happened sp snipped-for-privacy@yahoo.com wrote in :

Do not try too hard to understand my experiments. I come from a TV background, analog, PAL, build some PAL coders and decoders the analog way. The 200MHz in first instance came from the first thing I tried, the PAL encoder.

As I wanted to try it as time base corrector for VHS, there is a need to delay every horizontal line a different amount, so it starts where the H PLL's slow time constant averages. In analog times this was done with a L C L C.. delay line where C was a varicap.... Continuosly variable (Ampex had the Amtec and Colortec units) to withing nano second precision (AMTEC was Automatic Time Element Compensation) and Colortec the same but more accurate for color. In digital we can only shift the line start time in steps, 20ns steps if 50MHz. If you also shift the sub carrier and chroma, and with VHS source timing errors per line can be near the microsecond range you shift color phase for > 1 period! If you shift the burst too, then you destroy the line to line burst phase relationship. All this leads to a need for a very fine step size if you want to maintain phase. Not a good solution to correct original composite (while it is still composite). VHS uses an analog heterodyne system to keep color phase correct while H changes..... Anyways some experiments I did with this, and 200MHz clock also comes from that.

If you look up the chip that others suggested, the AL250_251.pdf datasheet, you find they say 'the output is better then the input', they really claim that. Well it all depends on what part of 'output' you look at I guess :-) Anyways they have the digitising done by an other chip, the SAA7111, and if you look at that datasheet you will find that they actually use an _ANALOG_ PLL to make the clocks!! (Page 30 pdf 'clock system').

That is why I wrote 'analog is better LOL'. Digital is by its nature limited to a discrete time step.

My conclusion after my experiments is about this: Use an analog color decoder, with analog PLL and 8.86 Mhz (2x fc) for PAL. Use a normal 64 us glass delay line for PAL (somebody is gona challenge this). Once you have UV (or QI), digitise at whatever speed you think you need for the resolution you want, sequentially (Y, U, Y, V) with a 3 to 1 demultiplexer and one ADC. Store in block rams in the Spartan. (Spartan 2 block ram is 4 bits wide, so use

2 for 8 bits wide), with 512 samples / line you are fine, read out at double speed. (15625 line freq and 512 samples = 8 MHz sample clock (VHS source), if you want 1024 Y samples use 16MHz clock, and double the amount of block rams.). UV (IQ) are sampled at half speed and together fill up 2 more block rams, total 4 (or 8) block rams. Do the YUV (YIQ) to RGB at double speed, send to 3 DACS. I left out the filtering.

Of course 'we have the FPGA board and now we play and try every thing we always wanted to try', But to think 'digital is always better' is not correct, or I can do this better in digital is not always correct either. It goes a long way, even the composite out of my rather expensive ASUS graphics card in the PC creates wrong colors :-) Not all chips are made equal.... The digital output from my Mustek DVD player is very different from the Cyberhome (that one is better, different chipset) DVD player.

So when they come with 'the output is better then the input' you better be the judge of that yourself. :-) So by all means try it digital, if you can do it with a 50MHz clock in Spartan

3...... let us know about it!

But if your intention is to watch those movies, OK I have read LCD is replacing CRT. Not that LCD has a better picture, but they managed to convince people Saddam had nukes too. Now at the border of s.e.d I will stop here.

Reply to
Jan Panteltje

Don't forget an OSD (on screen display) for messages and subtitles.

Reply to
a7yvm109gf5d1

Whew, quite a challenge. Is there some good reason you're doing this the hard way? Your basic $89 TV does this with a few analog chips, which should be rather economically priced due to the volume of course.

Doing it digitally is a bit challenging as you need rather precise phase lock to the 3.5xx subcarrier and differential phase with gain tracking.

Reply to
Ancient_Hacker

You may want ot read this, note 2.5ns in the late sixties and seventies:

formatting link
Fun for me as I worked with that stuff.

Reply to
panteltje

For small lots and prototyping the techs here (Dartmouth Physics Dept) find the solder paste is more problematic than using rosin-core wire solder and a fine iron (lead containing solder only). There is one fancy soldering station with capability for dealing with paste, but the paste has shelf-life problems, and old paste is very problematic.

Of course, using an iron only works for the surface mount versions where exposed metal is available: SO-8, discretes down to 0508, 0406, (pads deliberately oversized to expose metal) and a little bit of the MSOP stuff.

YMMV

Reply to
Kevin G. Rhoads

True, the commercial market has a lot more potential for custom low-run designs. However, it'll be awhile before I'm comfortable marketing any type of design - whether targetted towards the consumer or commercial market. This is strictly a learning project. I'm at minimum a few years off from being able to design this type of thing in an economical manner - at least on my own. There are many broad fields that I am inexperienced in (ie PCB design). However, I do plan on going into DSP and mixed-signal work, so I think this is a good project to use to become familiar with various techniques.

Reply to
sp_mclaugh

Very impressive, I gave the site a read. I'm sure that I couldn't do this with the technology from that time period ! Even now, it's going to be difficult. At least I don't have to deal with any time base corrections - I'm just going to use a broadcast video source.

Sean

Reply to
sp_mclaugh

The quick answer is... no. It's more of an exercise than a practical design.

See, I'm still trying to understand why the needed level of precision is difficult to attain. In my case, I'm oversampling by quite a bit (50 MSPS for a ~3.5 MHz signal). My sampling clock comes directly from the FPGA clock - fixed and stable. It is free-running, and bears no relation to the hsync or color subcarrier timing.

I regenerate the chroma subcarrier using a numerically controlled oscillator, which generates two outputs 90 degrees out of phase. The NCO is digitally phase locked to the color burst. I seperate the chroma from the luminance using a comb filter (2d adaptive). Then I just do coherent demodulation - multiply the chrominance by the outputs of my numerically controlled oscillator, and low-pass filter. This gives I and Q.

Where, specifically, do I have to worry most about the precisi> For small lots and prototyping the techs here (Dartmouth Physics Dept)

I'll see if I can find a fine soldering iron in one of our labs. However, my hand isn't all that steady to begin with, so we'll see...!

Reply to
sp_mclaugh

practical

precision

I don't see any major holes in your reasoning.

Your reference clock is something to pick with care. 50 MSPS is enough for video or direct IF processing (presuming IF is band-limited, as in the case with a tuner's SAW filter output). In your case (M NTSC), a commonly used I.F. is centered at 44 MHz, with the PIF at 45.75 and SIF at 41.25. Zarlink Semi uses a 20.45 MHz reference (multiplied by 2x for DSP), Micronas uses 18.432 MHz, others use 27 Mhz. Each has advantages and drawbacks. If you want to plan ahead for the direct I.F. demod I would suggest carefully plotting out the sampling components and their aliases. Later you might want to add PAL, SECAM, ATSC and DVB-T. It's very important to make sure your sampling reference is low-jitter (low SSB phase noise oscillator) and that you don't use the FPGA's internal PLL to multiply it for sampling (DSP clock is ok) but you will need a FIFO or some way to cross from clean to dirty clocking boundary. The reason a low phase-noise sampling is important is the chroma domod is very senitive to errors and this will show up in the video as chroma noise and color streaking. One other recommendation: For the filtering, you may eventually want to consider a combination of other topologies instead of a (symetric) FIR:

1) Group-delay compensated IIR - for video / I.F. filtering: it's more economical. 2) CIC - differentiator structure followed by a resonator (integrator) (See Kuc Introduction to Digital Signal Processing)

Forget the easy way - your approach, properly implemented, will yield the best result.

The hard part is the Audio - are you intending to demodulate BTSC stereo? I recommend doing the video first.

Regards,

Frank Raffaeli

formatting link

Reply to
Frank Raffaeli

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.