Digital processing of analog TV broadcast
in [Design]
|
From: sp_mclaugh on 5 Dec 2006 14:07 Comments below Frank Raffaeli wrote: > > 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. I suppose my thinking (perhaps wrong) was "It seems likely that the time jitter in my clock scales as some proportion of my clock period. ie, perhaps a 20ns clock (50MHz) would have 1ns time jitter, while a 40ns clock (25MHz) might have 2ns time jitter. (figures are fictional, but equal to 5% of clock period). Since I'm oversampling by so much (by using a faster clock), perhaps jitter isn't going to be a problem. In other words, the guys sampling at 4* Fsc, which is around 12 MHz, can only tolerate a clock with X percent jitter, while I can tolerate almost 5*X percent jitter in my 50 MHz clock." Is that line of reasoning at least *somewhat* rational? Like I said, clock specs are not my strong point. > "Oscillator design and Computer simulation" (Rhea) has a short bit > about xtal oscillator design. There are many other (perhaps better) > references. I will try to see if my library can get a loan of this. Thanks. > 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). Ahh, glad to see you've tried and saved me the trouble. > 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. Ahh, I haven't used that trick before. Brilliant. > Also, check these tricks: > http://www.dspguru.com/comp.dsp/tricks/tricks.htm Thanks. > What is limiting the bandwidth of your source signal? It's important to > have a flat group-delay filter. In this stage, I'm literally attaching a composite video (RCA) header to my board and feeding it to my ADC (with video clamping and built in sample-and-hold, might even get one with AGC). For testing, I have an older CATV converter box with composite video output that I can use, or I can use an old console game system, etc. I'm assuming there's no high frequency left on the baseband signal, so that no further filter is necessary at all. Should be cut off at 6 MHz max, though it'll be around 4.2 MHz for broadcast signals. Should I be wary of the filters used inside the CATV converter box? Thanks again, Sean
From: Jan Panteltje on 6 Dec 2006 06:09 On a sunny day (5 Dec 2006 10:48:08 -0800) it happened sp_mclaugh(a)yahoo.com wrote in <1165344488.217771.131120(a)80g2000cwy.googlegroups.com>: > >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 >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 Yes I expected somebody to come with that counter argument. Although it is mathematically correct. And those filters can be made with sufficient FPGA real estate. Now as we multiply with sin(f) etc... we need a closer look at that. You mentioned using a 'crude' lookup table? I have been thinking about that, there are algos like CORDIC too..... But also the phase must be right. And you want the values from a 20ns clock. Here it gets tricky, and that is why I used an external 8.86 MHz xtal for PAL (fc = 4.43, you would need 2x 3.56 Mhz?). With a varicap you can then tune it so it is phase lock.... and you can make 90 degrees separated clocks from the 8.83, worked that one out in the seventies..... I will not drop the subject, and will keep thinking about it. It may sound like defeat to use an analog part these days (I mean not to do it all in one chip in digital), but OK, the end result counts. As a radio man too, when we multiply frequencies, and it ain't no pure sine waves, I get visions of interference and harmonics and if the interferences of any the components result in a signal within the passband of the signal you actually want you are in trouble. I hope your 'crude' lookup table will get you sufficient phase accuracy and no strange side effects?
From: sp_mclaugh on 9 Dec 2006 13:28 Frank Raffaeli wrote: > 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. After doing some searching for "ADC FIFO", almost everything I found was about people using DSP processors (SHARC etc) who wanted to use an FPGA *as* the FIFO. Perhaps an external register / FIFO won't be necessary ? Jan Panteltje wrote: > Yes I expected somebody to come with that counter argument. > Although it is mathematically correct. > And those filters can be made with sufficient FPGA real estate. The real estate is certainly a concern. I might not be able to use the Spartan 3 that I'm currently using. > Now as we multiply with sin(f) etc... we need a closer look at that. > You mentioned using a 'crude' lookup table? > I have been thinking about that, there are algos like CORDIC too..... > But also the phase must be right. > And you want the values from a 20ns clock. Well, I don't know if I'd say "crude". I did mention that the table will have an N bit index, with significantly less than 2^N table elements. But don't get me wrong, the table will still be fairly large. It's just that I'm getting some extra precision by interpolating (using the extra bits). I think some people call this DDS (direct digital synthesis). > Here it gets tricky, and that is why I used an external 8.86 MHz xtal > for PAL (fc = 4.43, you would need 2x 3.56 Mhz?). > With a varicap you can then tune it so it is phase lock.... and you > can make 90 degrees separated clocks from the 8.83, worked that one > out in the seventies..... Ah, so did you use a sinusoidal oscillator (locked w/ chroma subcarrier), analog multiplier, and analog filters? > I will not drop the subject, and will keep thinking about it. > > It may sound like defeat to use an analog part these days (I mean > not to do it all in one chip in digital), but OK, the end result counts. It would sure be a lot cheaper, too. I suppose I'm just being stubborn and trying to see if I can do it digitally. There are pros and cons to each way. For example, digital filters can do things that analog filters couldn't dream of doing. > As a radio man too, when we multiply frequencies, and it ain't no pure > sine waves, I get visions of interference and harmonics and if the > interferences of any the components result in a signal within the passband > of the signal you actually want you are in trouble. Hmm, I wonder how much interference we're talking about. And, of course, whether it causes more or less problems than sampling every 90 degrees (I, Q, I, Q), with some (realistic) allowed margin for being out-of-phase. I always thought of the synchronous/coherent demodulation as being superior, but maybe not... ? Thanks, Sean
From: Jan Panteltje on 9 Dec 2006 14:37 On a sunny day (9 Dec 2006 10:28:46 -0800) it happened sp_mclaugh(a)yahoo.com wrote in <1165688926.628422.252080(a)j44g2000cwa.googlegroups.com>: >Jan Panteltje wrote: > >> Yes I expected somebody to come with that counter argument. >> Although it is mathematically correct. >> And those filters can be made with sufficient FPGA real estate. > >The real estate is certainly a concern. I might not be able to use the >Spartan 3 that I'm currently using. Yes there is quite a bit of filers and so multipliers needed. i made a nice video low-pass, then a chroma bandpass filter. Spartan2-300. There was space left, use less poles more ripple :-) >> Now as we multiply with sin(f) etc... we need a closer look at that. >> You mentioned using a 'crude' lookup table? >> I have been thinking about that, there are algos like CORDIC too..... >> But also the phase must be right. >> And you want the values from a 20ns clock. > >Well, I don't know if I'd say "crude". I did mention that the table >will have an N bit index, with significantly less than 2^N table >elements. But don't get me wrong, the table will still be fairly large. >It's just that I'm getting some extra precision by interpolating (using >the extra bits). I think some people call this DDS (direct digital >synthesis). OK, got it. >> Here it gets tricky, and that is why I used an external 8.86 MHz xtal >> for PAL (fc = 4.43, you would need 2x 3.56 MHz?). >> With a varicap you can then tune it so it is phase lock.... and you >> can make 90 degrees separated clocks from the 8.83, worked that one >> out in the seventies..... > >Ah, so did you use a sinusoidal oscillator (locked w/ chroma >subcarrier), analog multiplier, and analog filters? Yes and no, the oscillator is a junction FET with 8.83 Mhz xtal, but then goes into a Schmitt trigger and the square wave enters the FPGA. I made a nice PAL quadrature encoder some time ago (years) with CMOS 4053 switches (the idea I got from some Elector article) could dig up that diagram, using a 2 inverter TTL oscillator at 8.83. In the same way you can either sample via a AD, or use drive CMOS switches to sample, here is some circuit that is analog, but digital anyways :-) --- -------- ------------ | | | | ------- -------- A 4.43 square wave osc out from FPGA after division of the 8.86 MHz input. - - | | | | --------- -------------- ------------ B sample pulse from FPGA 8.86 MHz oscillator + 4016 CMOS switch varicap | \ R ||/| |--- A ---------- \-----------===------------------|| |------------------->| JFET | | | ||\| | | | |--- | === [ ] | [ ] === |--------> to Schmitt trigger B | | | | | | NAND /// === --- /// |----------| the NAND output | = | | enters as clock /// --- 8.86M === [ ] in the FPGA loop filter | | | /// /// /// Pulse B will adjust around the leading edge of A, where the voltage after the filter is 2.5V. The more narrow pulse B, the more precise the phase alignment, to a point. So the phase comparator is digital :-) If you divide the 8.86 by 2 and / or use pos edge for U and neg edge for V (I and Q NTSC, and other frequency) you have your 90 degrees. You can then make the demodulator with these CMOS switches too :-) If you provide chroma in 0 and 180 degrees (inverted) you can sample twice as fast. Yes I used analog pre-emphasis filters, simple CLC filters. >> I will not drop the subject, and will keep thinking about it. >> >> It may sound like defeat to use an analog part these days (I mean >> not to do it all in one chip in digital), but OK, the end result counts. > >It would sure be a lot cheaper, too. I suppose I'm just being stubborn >and trying to see if I can do it digitally. There are pros and cons to >each way. For example, digital filters can do things that analog >filters couldn't dream of doing. > >> As a radio man too, when we multiply frequencies, and it ain't no pure >> sine waves, I get visions of interference and harmonics and if the >> interferences of any the components result in a signal within the passband >> of the signal you actually want you are in trouble. > >Hmm, I wonder how much interference we're talking about. And, of >course, whether it causes more or less problems than sampling every 90 >degrees (I, Q, I, Q), with some (realistic) allowed margin for being >out-of-phase. I always thought of the synchronous/coherent demodulation >as being superior, but maybe not... ? I dunno, lookup TDA3560.pdf, an analog PAL demodulator chip, look at the application diagram. _Worst case_ 5 degrees error, RGB out, note the delayline. They do everything in 8,86 Mhz, differential multipliers in that chip I think. That was 1980, filters what filters? 5V pp out RGB and max 150 mV left of the 8.86 (symmetry I guess). LC rules, note how the direct chroma is added to the delayed via a _trimpot_. The 90 degrees is done in the chip. Note the output transformer with 0 / 180 degrees (center tap :-) to get 180 degrees accurate chroma phases. I have that chip and stuff, was in almost every Philips color TV in those days, as a module. NTSC is a bit simpler, omit the delay line and PAL switch flip flop, and related sync. (In PAL the R-Y modulator carrier is flipped 180 degrees each line. Because B-Y is not switched, the burst, which is simply the vector sum, swings 90 degrees. These cause a 1/2 H component on the filter of the above PLL. That is then used to sync a line triggered FF that switches the R-Y carrier 180 degrees each line in the demodulator. One could of course also switch chroma phase. When we digitise I Q (U V, R-Y, B-Y) we can store R-Y for a line, and add with the current line and we need no 4.42 MHz chroma delay line. If you do not do that then eye will have to average any error over 2 lines, this is called 'simple PAL". So maybe after you do the NTSC thingy you can start with the PAL design ;-)
From: sp_mclaugh on 9 Dec 2006 22:23
Jan Panteltje wrote: > Yes and no, the oscillator is a junction FET with 8.83 Mhz xtal, but > then goes into a Schmitt trigger and the square wave enters the FPGA. I see. > I made a nice PAL quadrature encoder some time ago (years) with CMOS 4053 > switches (the idea I got from some Elector article) could dig > up that diagram, using a 2 inverter TTL oscillator at 8.83. > In the same way you can either sample via a AD, or use drive CMOS > switches to sample, here is some circuit that is analog, but digital anyways :-) Wow, pretty neat idea. BTW, do you do the ASCII art by hand or with a program? Looks pretty good, I'd be too lazy to do that much by hand. :-) > I dunno, lookup TDA3560.pdf, an analog PAL demodulator chip, look at the > application diagram. > _Worst case_ 5 degrees error, RGB out, note the delayline. I didn't do out the exact calculations, but I seem to recall that would mean you'd introduce Sin[5 deg] * 100% = 8.7% of I into Q and vice-versa. Don't take my word for it though. Maybe I'll dig up a book or do it out myself if I remember to. Beyond this calculation, I think it's up to the physiology people to explain what the average human perceives as more offensive... > LC rules, note how the direct chroma is added to the delayed via a _trimpot_. nice > So maybe after you do the NTSC thingy you can start with the PAL design ;-) Haha, perhaps I could. Actually though, I think my next project will be decoding broadcast HDTV (maybe 8-VSB, though I don't know yet, it'll be awhile). One other question for you. I've dediced that I'm definitely using the Philips TDA8708A that you recommended. I have enough to deal with on the digital side, without worrying about DC restoration (video clamping), auto gain control, and sample-and-hold. The TDA8708A seems like a prototyper's dream come true. I have two questions though. 1 - Did you use the recommended 5th order Chebyshev filter that is shown in the TDA8708A datasheet? It's on page 17, and consists of 2 resistors, 2 inductors, and 5 caps. Looks pretty easy, being a total of only 9 passives. They also show an alternate schematic on p18, but the frequency response isn't as flat in the passband. 2 - What did you do to generate the required clamping pulses? ie, pins 26 (black level sync pulse) or pin 27 (sync level sync pulse)? I think you only have to use one of them. Did you generate the pulses digitally in the Spartan, or use a seperate analog sync extractor? I figure that I already have to look for the hsync pulses in the FPGA, so I could probably do it that way... But it might be more robust to use a dedicated chip. BTW, I'm also planning on making a digital storage oscilloscope down the line. Would the TDA8708A function as a regular ADC (no clamping) if those two pins were just tied to ground? It's still the best and cheapest DIP ADC I can find. I got it for like 6 bucks. Any other peculiarities to worry about with the TDA8708A, or any warnings? I'm planning to breadboard it, so I hope I don't have problems with inadequate grounding... I've heard of people using breadboards and getting huge spikes on their analog signal whenever the clock strikes. I think they were using a different ADC, but... Ooh, that reminds me, time to order a high density DSUB header and an RCA header... Thanks again, Sean |