Digital processing of analog TV broadcast
in [Design]
|
From: sp_mclaugh on 30 Nov 2006 17:28 Frank Raffaeli wrote: > If you want to plan ahead for the direct I.F. demod I would suggest > carefully plotting out the sampling components and their aliases. It is possible that I will do this later, but it won't be any time soon. I'm just using a premade RF front end for now. > 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. Would you mind elaborating a bit on how to do the above? Is there a good reference that I should look at? I'm very much an amateur with clock specifications, though I thought I could avoid the issue altogether with my method. For baseband video (not direct IF), do I really need to worry about clock jitter (within reason) if I'm oversampling by such a large amount? > 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) Thanks, I was looking for better filter methods! I knew that FIR filters aren't the most efficient, but I wasn't confidant enough with other filters to choose an alternative. > Forget the easy way - your approach, properly implemented, will yield > the best result. I appreciate the encouragement, hopefully I'll get this working... > The hard part is the Audio - are you intending to demodulate BTSC > stereo? I recommend doing the video first. I have no plans for audio in the near future. If I use direct IF sampling, of course, I'll have to worry about it then. - Sean
From: Glenn Gundlach on 1 Dec 2006 03:33 sp_mclaugh(a)yahoo.com wrote: > 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: > <snip> > Sean And after Feb 2009 when the analog TV system (at least over the air) is turned off, you will want this why? GG
From: sp_mclaugh on 1 Dec 2006 14:31 Glenn Gundlach wrote: > And after Feb 2009 when the analog TV system (at least over the air) is > turned off, you will want this why? > > GG I won't. But at least I'll have gotten familiar with QAM digital demodulation, filter design, DPLL's, resampling, etc. That will be useful for a long time. Sean
From: Frank Raffaeli on 4 Dec 2006 01:23 On Nov 30, 5:28 pm, sp_mcla...(a)yahoo.com wrote: > FrankRaffaeliwrote: > > If you want to plan ahead for the direct I.F. demod I would suggest > > carefully plotting out the sampling components and their aliases.It is possible that I will do this later, but it won't be any time > soon. I'm just using a premade RF front end for now. > > > 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.Would you mind elaborating a bit on how to do the above? Is there a > good reference that I should look at? I'm very much an amateur with > clock specifications, though I thought I could avoid the issue > altogether with my method. For baseband video (not direct IF), do I > really need to worry about clock jitter (within reason) if I'm > oversampling by such a large amount? Most off-the shelf crystal oscillators will do ok. Oversampling and jitter aren't correlated directly. "Oscillator design and Computer simulation" (Rhea) has a short bit about xtal oscillator design. There are many other (perhaps better) references. I've tried using Xilinx Virtex4's built-in PLL and also Altera's Cyclone2 for video clocking and for chroma demod. Both recommend using filtering on the PLL supply. This works well enough for the video horizontal time base output to the DAC, but not well enough to prevent chroma streaking on a large display (from the sampling phase noise introduced by the PLL). Use the crystal oscillator (un-multiplied - no PLL) for sampling the ADC. Then clock the ADC output into a FIFO. Read the FIFO with your internal PLL reference (DSP clock.) This is a standard trick. Also, check these tricks: http://www.dspguru.com/comp.dsp/tricks/tricks.htm What is limiting the bandwidth of your source signal? It's important to have a flat group-delay filter. Thanks, Frank
From: sp_mclaugh on 5 Dec 2006 13:48
Jan Panteltje wrote: > So maybe the great mathemagicians will now care to explain where the error > goes when you sample Q where I is not zero, and I where Q is not zero. > I can think of some great test signals. > Also for 44100 sampled audio. > Be honest. See, since my sampling clock has no relation to the chroma subcarrier, I'm going to have to sample in the way you described above. That is, when neither I nor Q are zero. But, as I understand it, it isn't too hard to seperate I and Q using this method (synchronous/coherent demodulation). It has to do with the orthogonality of sin and cos. Basically, your transmitted QAM signal is: msg1 * Cos[f*t] + msg2 * Sin[f*t] When you multiply by cos(f*t), you get: msg1 * Cos[f*t]^2 + msg2 * Cos[f*t] Sin[f*t] Which you can use trig properties to expand: msg1*(1/2)*(1+Cos[2*f*t]) + msg2*(1/2)*Sin[2*f*t] When you lowpass filter this, you just get: msg1/2 To get the other message, multiply by sin(f*t), giving: msg1 * Cos[f*t] Sin[f*t] + msg2 * Sin[f*t]^2 Use trig properties again to get: msg1*(1/2)*Sin[2*f*t] + msg2*(1/2)*(1-Cos[2*f*t]) Use a lowpass filter again to get: msg2/2 Hopefully I didn't make any mistakes above, I didn't have my book in front of me, but I'm pretty sure that's how it goes. Is this what you were talking about, or something else? Anyways, thanks for the continued posts. Sean |