|
From: | Andres Campos Santana |
Subject: | Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER |
Date: | Sat, 25 Aug 2018 20:15:00 +0000 |
I tried to listen to the NTSC channel audio using a FM receiver I made, and I got it, I could listen to it perfectly. That should be a good way to prove that I'm receiving the channel signal, for that reason, I don't understand why I just receive a diffuse mix of black, white and gray image instead of perceiving a moving black and white moving images. I understand I can't receive a colour image due to the RTL bw (2MHz).
I was talking with Martin and he told me this problem would be due to my sound card isn't sampling as fast as the program needs or my proccesing unit doesn't support it. I have Intel® Core™ i5-3210M CPU @ 2.50GHz × 4 in a Lenovo Thinkpad t430 computer. The program that I am guiding myself is well done since in the results you can see that black and white television.
What do you think about this problem? Thanks for your help!
Andrés.
De: Discuss-gnuradio <discuss-gnuradio-bounces+address@hidden> en nombre de Martin McCormick <address@hidden>
Enviado: sábado, 25 de agosto de 2018 18:12 Para: address@hidden Asunto: Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER I must think a little better next time. I looked at my
posting to the list and realized I was being rather dim-witted in that I was imagining the signal path for the video as needing the sound card as it does when one is decoding the sound carrier or an FM radio station. In theory, one could do that if you could make the circuitry in the sound card run a lot faster than it normally does but that isn't necessary at all. The I and Q signals from the rtl chip first go to a processing block to add their vectors in a floating point method just like all other analog processing but much more frequently. You still need a low-pass filter to prevent aliasing just as with audio and low-speed data but the frequency is much higher since we are taking lots more samples per second. That block must run a lot faster all right. Each computed level represents one pixel and here's the first spot where there could be trouble. If the processor can't do the math fast enough, the next sample arrives and the first one hasn't been set yet. We are already behind and there is no flow-control so something is going to give and it is most likely going to be no or badly-formed pixels which will mean no picture at all. These calculations as well as the placement of each pixel will be being done at the usb sampling rate so I bet the newest and best hardware will probably decode the monochrome image and systems like the 600-MHZ Pentium I do unix command-line, audio and email on would positively smoke if I tried to do this there. I believe the DSP chips used in dedicated DSP devices use every trick in the book to process rapidly and general-purpose computers have much more difficulty keeping up. Many people on this list know far more about this than I do so feel free to call me out but in theory, if you sampled at 12 MHZ, one could generate a digital stream that if run through a D/A converter would be a full color NTSC picture and the full audio carrier which would need a second decoder if you wanted the sound but it is possible. If you ran the first D/A through an oscilloscope, you would see the full video envelope plus the sound carrier at 4.5 MHZ. It would be a NTSC base band signal. The same is true for PAL and SECAM but one would need 14 or 16 MHZ sampling rates to capture those formats. Martin WB5AGZ _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|
[Prev in Thread] | Current Thread | [Next in Thread] |