Digital processing of analog TV broadcast
in [Design]
|
From: sp_mclaugh on 27 Nov 2006 17:47 linnix wrote: > a7yvm109gf5d1(a)netzero.com wrote: > > Is there any reason you are re-inventing the wheel? > > I second this. Unless you are doing some additional processings, which > would require external memories anyway. Yes, I am doing this project just as a way to understand the underlying components. Basically, I am intentionally trying to "reinvent the wheel". Also, I'll have these components as intellectual property for future projects. It is strictly educational, I'm not producing anything for future sale. Actually, I'm going to use it for part of a final project in an FPGA design class I'm in. It's not the cheapest or most efficient way to do it, but like I said... 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) > > Averlogic AL250 > > + > > Philips SAA7111 (or is that NXP?) > > > > Total cost about 30$. > > Add $10 more for a graphic chip (VGA output).
From: Jan Panteltje on 28 Nov 2006 08:26 On a sunny day (27 Nov 2006 14:39:50 -0800) it happened sp_mclaugh(a)yahoo.com wrote in <1164667190.438191.10500(a)l12g2000cwl.googlegroups.com>: >> Analog is better? Looks like it! >> LOL > >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. 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.
From: a7yvm109gf5d1 on 28 Nov 2006 11:34 sp_mclaugh(a)yahoo.com wrote: > linnix wrote: > > a7yvm109gf5d1(a)netzero.com wrote: > > > Is there any reason you are re-inventing the wheel? > > > > I second this. Unless you are doing some additional processings, which > > would require external memories anyway. > > Yes, I am doing this project just as a way to understand the underlying > components. Basically, I am intentionally trying to "reinvent the > wheel". Also, I'll have these components as intellectual property for > future projects. It is strictly educational, I'm not producing anything > for future sale. Actually, I'm going to use it for part of a final > project in an FPGA design class I'm in. It's not the cheapest or most > efficient way to do it, but like I said... OK, sounds good, but what's the point of having IP on something that already exists as an ASIC? You won't make a competitive consumer product that way. I've seen industrial scan doublers for 2000$ OTOH. > > 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) Don't forget an OSD (on screen display) for messages and subtitles.
From: Ancient_Hacker on 28 Nov 2006 11:59 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. 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.
From: panteltje on 29 Nov 2006 10:33
sp_mclaugh(a)yahoo.com schreef: > linnix wrote: > > a7yvm109gf5d1(a)netzero.com wrote: > > > Is there any reason you are re-inventing the wheel? > > > > I second this. Unless you are doing some additional processings, which > > would require external memories anyway. > > Yes, I am doing this project just as a way to understand the underlying > components. Basically, I am intentionally trying to "reinvent the > wheel". You may want ot read this, note 2.5ns in the late sixties and seventies: http://www.labguysworld.com/Museum014.htm Fun for me as I worked with that stuff. |