Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Adrian Musceac]

Hi Marcus,

You're right about the RTL sample rate, but I'm curious about why it is so 
small.
Is it the bus speed? The ADC is obviously fast enough for DVB-T2.

Regards,
Adrian

On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)"  
wrote:
>Hi Martin,
>
>internally, the RTL dongles are fast enough to capture full DVB-T (not
>-T2) channels, and demodulate, and decode them, and deliver the video
>stream to the host. However, RTL-SDR can't use that mode - it uses a
>"bypass the whole Digital TV specific stuff" mode and directly passes
>IQ samples through USB.
>
>In that mode, it simply can't do more than 2 or 3 MS/s (can't
>remember), which isn't enough to cover 6 MHz - so everyone's right, you
>can basically receive the AM black/white info at a partial bandwidth of
>the ca 5 MHz of the luma signal, but you won't get any color
>information that way, or audio with the same receiver as you do video.
>
>Cheers,
>Marcus 
>
>On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:
>>  First, I will talk about the things I know for sure.  The
>> NTSC analog system as well as Pal systems in a lot of the rest of
>> the world had a lot in common with eachother.  Both systems
>> transmitted an AM video signal in Vestigial single sideband mode
>> such that the carrier frequency was always about 1.25 MHZ above
>> the start of a channel.  NTSC systems in the Americas also
>> transmitted an audio carrier in FM which was always 4.9 MHZ above
>> the video carrier.  Pal systems used exactly the same type of
>> transmissions except that the 625-line video at 25 frames per
>> second made a slightly wider spectrum such that the audio and
>> video carriers were separated by 5.x MHZ, making each Pal channel
>> 7 or 8 MHZ wide.
>> 
>>  As others have suggested, you could probably get a
>> monochrome fuzzy image if you can get your sound card to sample
>> fast enough.  You can also decode the mono sound by setting your
>> RTL receiver to behave just like a FM broadcast receiver but set
>> the frequency to whatever the video carrier frequency is plus 4.5
>> MHZ.  if the video carrier is 55.250 MHZ, the audio will be at
>> 59.75 MHZ.  The deviation is 75 KHZ unlike FM radio which is 150
>> KHZ.
>> 
>>  That would be a good simple test to see if you are
>> receiving the channel at all.
>> 
>>  I am guessing that since the RTL chips were designed for
>> the European television market for cable and over-the-air
>> broadcasts, they can be sampled extremely fast since the digital
>> channels still take up the same bandwidth as their analog
>> ancestors.
>> 
>>  Martin McCormick WB5AGZ
>> 
>> Anders Hammarquist  writes:
>> > In a message of Fri, 24 Aug 2018 10:27:40 +0200, "Ralph A. Schmid, 
>> > dk5ras" writes:
>> > > > Hi Andres,
>> > > > 
>> > > > just had a short look: doesn't NTSC use a nearly 6 MHz
>> > > > bandwidth?
>> > > > 
>> > > > Best regards,
>> > > > Marcus
>> > > 
>> > > Yes, no way with the RTL to catch NTSC, it does in SDR mode only
>> > > 2.smth 
>> > 
>> > MHz bandwidth.
>> > 
>> > Actually, you should be able to get a picture. The horizontal
>> > resolution 
>> > will be
>> > about half of what it would be for the full bandwidth, and no
>> > colour (as 
>> > the colour
>> > subcarrier at 3.58 MHz is outside the pass band). You want the pass
>> > band 
>> > of the reciever
>> > from just below the video carrier and as high as it will go.
>> > 
>> > /Anders
>> 
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Ron Economos]

The maximum Transport Stream rate of DVB-T is 31.67 Mbps, so the USB 
interface only needs to deliver 4 MB/s. Since you need two 8-bit samples 
in IQ mode, it's 2 Msps.


Ron

On 08/25/2018 12:44 AM, Adrian Musceac wrote:

Hi Marcus,

You're right about the RTL sample rate, but I'm curious about why it 
is so small.

Is it the bus speed? The ADC is obviously fast enough for DVB-T2.

Regards,
Adrian

On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)" 
 wrote:


Hi Martin,

internally, the RTL dongles are fast enough to capture full DVB-T (not
-T2) channels, and demodulate, and decode them, and deliver the video
stream to the host. However, RTL-SDR can't use that mode - it uses a
"bypass the whole Digital TV specific stuff" mode and directly passes
IQ samples through USB.

In that mode, it simply can't do more than 2 or 3 MS/s (can't
remember), which isn't enough to cover 6 MHz - so everyone's right, you
can basically receive the AM black/white info at a partial bandwidth of
the ca 5 MHz of the luma signal, but you won't get any color
information that way, or audio with the same receiver as you do video.

Cheers,
Marcus

On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:

First, I will talk about the things I know for sure. The NTSC
analog system as well as Pal systems in a lot of the rest of
the world had a lot in common with eachother. Both systems
transmitted an AM video signal in Vestigial single sideband
mode such that the carrier frequency was always about 1.25 MHZ
above the start of a channel. NTSC systems in the Americas
also transmitted an audio carrier in FM which was always 4.9
MHZ above the video carrier. Pal systems used exactly the same
type of transmissions except that the 625-line video at 25
frames per second made a slightly wider spectrum such that the
audio and video carriers were separated by 5.x MHZ, making
each Pal channel 7 or 8 MHZ wide. As others have suggested,
you could probably get a monochrome fuzzy image if you can get
your sound card to sample fast enough. You can also decode the
mono sound by setting your RTL receiver to behave just like a
FM broadcast receiver but set the frequency to whatever the
video carrier frequency is plus 4.5 MHZ. if the video carrier
is 55.250 MHZ, the audio will be at 59.75 MHZ. The deviation
is 75 KHZ unlike FM radio which is 150 KHZ. That would be a
good simple test to see if you are receiving the channel at
all. I am guessing that since the RTL chips were designed for
the European television market for cable and over-the-air
broadcasts, they can be sampled extremely fast since the
digital channels still take up the same bandwidth as their
analog ancestors. Martin McCormick WB5AGZ Anders Hammarquist
 writes:

In a message of Fri, 24 Aug 2018 10:27:40 +0200, "Ralph A.
Schmid, dk5ras" writes:

Hi Andres, just had a short look: doesn't NTSC use
a nearly 6 MHz bandwidth? Best regards, Marcus 


Yes, no way with the RTL to catch NTSC, it does in SDR
mode only 2.smth 


MHz bandwidth. Actually, you should be able to get a
picture. The horizontal resolution will be about half of
what it would be for the full bandwidth, and no colour (as
the colour subcarrier at 3.58 MHz is outside the pass
band). You want the pass band of the reciever from just
below the video carrier and as high as it will go. /Anders 






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Adrian Musceac]

Hi Ron,

So in theory, replacing the USB2 chip with a USB3 would allow access to the 
full sample rate, or is there some other internal limitation?

Regards,
Adrian

On August 25, 2018 8:06:20 AM UTC, Ron Economos  wrote:
>The maximum Transport Stream rate of DVB-T is 31.67 Mbps, so the USB 
>interface only needs to deliver 4 MB/s. Since you need two 8-bit
>samples 
>in IQ mode, it's 2 Msps.
>
>Ron
>
>On 08/25/2018 12:44 AM, Adrian Musceac wrote:
>> Hi Marcus,
>>
>> You're right about the RTL sample rate, but I'm curious about why it 
>> is so small.
>> Is it the bus speed? The ADC is obviously fast enough for DVB-T2.
>>
>> Regards,
>> Adrian
>>
>> On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)" 
>>  wrote:
>>
>> Hi Martin,
>>
>> internally, the RTL dongles are fast enough to capture full DVB-T
>(not
>> -T2) channels, and demodulate, and decode them, and deliver the
>video
>> stream to the host. However, RTL-SDR can't use that mode - it
>uses a
>> "bypass the whole Digital TV specific stuff" mode and directly
>passes
>> IQ samples through USB.
>>
>> In that mode, it simply can't do more than 2 or 3 MS/s (can't
>> remember), which isn't enough to cover 6 MHz - so everyone's
>right, you
>> can basically receive the AM black/white info at a partial
>bandwidth of
>> the ca 5 MHz of the luma signal, but you won't get any color
>> information that way, or audio with the same receiver as you do
>video.
>>
>> Cheers,
>> Marcus
>>
>> On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:
>>
>> First, I will talk about the things I know for sure. The NTSC
>> analog system as well as Pal systems in a lot of the rest of
>> the world had a lot in common with eachother. Both systems
>> transmitted an AM video signal in Vestigial single sideband
>> mode such that the carrier frequency was always about 1.25
>MHZ
>> above the start of a channel. NTSC systems in the Americas
>> also transmitted an audio carrier in FM which was always 4.9
>> MHZ above the video carrier. Pal systems used exactly the
>same
>> type of transmissions except that the 625-line video at 25
>> frames per second made a slightly wider spectrum such that
>the
>> audio and video carriers were separated by 5.x MHZ, making
>> each Pal channel 7 or 8 MHZ wide. As others have suggested,
>> you could probably get a monochrome fuzzy image if you can
>get
>> your sound card to sample fast enough. You can also decode
>the
>> mono sound by setting your RTL receiver to behave just like a
>> FM broadcast receiver but set the frequency to whatever the
>> video carrier frequency is plus 4.5 MHZ. if the video carrier
>> is 55.250 MHZ, the audio will be at 59.75 MHZ. The deviation
>> is 75 KHZ unlike FM radio which is 150 KHZ. That would be a
>> good simple test to see if you are receiving the channel at
>> all. I am guessing that since the RTL chips were designed for
>> the European television market for cable and over-the-air
>> broadcasts, they can be sampled extremely fast since the
>> digital channels still take up the same bandwidth as their
>> analog ancestors. Martin McCormick WB5AGZ Anders Hammarquist
>>  writes:
>>
>> In a message of Fri, 24 Aug 2018 10:27:40 +0200, "Ralph
>A.
>> Schmid, dk5ras" writes:
>>
>> Hi Andres, just had a short look: doesn't NTSC
>use
>> a nearly 6 MHz bandwidth? Best regards, Marcus 
>>
>> Yes, no way with the RTL to catch NTSC, it does in
>SDR
>> mode only 2.smth 
>>
>> MHz bandwidth. Actually, you should be able to get a
>> picture. The horizontal resolution will be about half of
>> what it would be for the full bandwidth, and no colour
>(as
>> the colour subcarrier at 3.58 MHz is outside the pass
>> band). You want the pass band of the reciever from just
>> below the video carrier and as high as it will go.
>/Anders 
>>
>>
>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Ron Economos]

It's all about making them as inexpensive as possible. The USB 
controller has just enough bandwidth for the intended purpose. On a 
consumer product, even a few cents makes a difference.


Ron

On 08/25/2018 01:13 AM, Adrian Musceac wrote:

Hi Ron,

So in theory, replacing the USB2 chip with a USB3 would allow access 
to the full sample rate, or is there some other internal limitation?


Regards,
Adrian

On August 25, 2018 8:06:20 AM UTC, Ron Economos  wrote:

The maximum Transport Stream rate of DVB-T is 31.67 Mbps, so the
USB interface only needs to deliver 4 MB/s. Since you need two
8-bit samples in IQ mode, it's 2 Msps.

Ron

On 08/25/2018 12:44 AM, Adrian Musceac wrote:

Hi Marcus,

You're right about the RTL sample rate, but I'm curious about why
it is so small.
Is it the bus speed? The ADC is obviously fast enough for DVB-T2.

Regards,
Adrian

On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)"
 wrote:

Hi Martin,

internally, the RTL dongles are fast enough to capture full DVB-T (not
-T2) channels, and demodulate, and decode them, and deliver the video
stream to the host. However, RTL-SDR can't use that mode - it uses a
"bypass the whole Digital TV specific stuff" mode and directly passes
IQ samples through USB.

In that mode, it simply can't do more than 2 or 3 MS/s (can't
remember), which isn't enough to cover 6 MHz - so everyone's right, you
can basically receive the AM black/white info at a partial bandwidth of
the ca 5 MHz of the luma signal, but you won't get any color
information that way, or audio with the same receiver as you do video.

Cheers,
Marcus

On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:

First, I will talk about the things I know for sure. The
NTSC analog system as well as Pal systems in a lot of the
rest of the world had a lot in common with eachother.
Both systems transmitted an AM video signal in Vestigial
single sideband mode such that the carrier frequency was
always about 1.25 MHZ above the start of a channel. NTSC
systems in the Americas also transmitted an audio carrier
in FM which was always 4.9 MHZ above the video carrier.
Pal systems used exactly the same type of transmissions
except that the 625-line video at 25 frames per second
made a slightly wider spectrum such that the audio and
video carriers were separated by 5.x MHZ, making each Pal
channel 7 or 8 MHZ wide. As others have suggested, you
could probably get a monochrome fuzzy image if you can
get your sound card to sample fast enough. You can also
decode the mono sound by setting your RTL receiver to
behave just like a FM broadcast receiver but set the
frequency to whatever the video carrier frequency is plus
4.5 MHZ. if the video carrier is 55.250 MHZ, the audio
will be at 59.75 MHZ. The deviation is 75 KHZ unlike FM
radio which is 150 KHZ. That would be a good simple test
to see if you are receiving the channel at all. I am
guessing that since the RTL chips were designed for the
European television market for cable and over-the-air
broadcasts, they can be sampled extremely fast since the
digital channels still take up the same bandwidth as
their analog ancestors. Martin McCormick WB5AGZ Anders
Hammarquist  writes:

In a message of Fri, 24 Aug 2018 10:27:40 +0200,
"Ralph A. Schmid, dk5ras" writes:

Hi Andres, just had a short look: doesn't
NTSC use a nearly 6 MHz bandwidth? Best
regards, Marcus 


Yes, no way with the RTL to catch NTSC, it does
in SDR mode only 2.smth 


MHz bandwidth. Actually, you should be able to get a
picture. The horizontal resolution will be about half
of what it would be for the full bandwidth, and no
colour (as the colour subcarrier at 3.58 MHz is
outside the pass band). You want the pass band of the
reciever from just below the video carrier and as
high as it will go. /Anders 









___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Kyeong Su Shin]

Hello Adrian,


The USB interface is integrated in the RTL-SDR chip (RTL2832U), so it cannot be 
replaced (as far as I know).


In theory, USB 2.0 can support faster data rates (HackRF does 16 MS/s - 20 MS/s 
with USB 2.0 8 bit I-Q). As Ron mentioned, it is due to the cost reduction.


Regards,

Kyeong Su Shin



보낸 사람: Adrian Musceac  대신 Discuss-gnuradio 

보낸 날짜: 2018년 8월 25일 토요일 오후 5:13:09
받는 사람: discuss-gnuradio@gnu.org; Ron Economos
제목: Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

Hi Ron,

So in theory, replacing the USB2 chip with a USB3 would allow access to the 
full sample rate, or is there some other internal limitation?

Regards,
Adrian

On August 25, 2018 8:06:20 AM UTC, Ron Economos  wrote:

The maximum Transport Stream rate of DVB-T is 31.67 Mbps, so the USB interface 
only needs to deliver 4 MB/s. Since you need two 8-bit samples in IQ mode, it's 
2 Msps.

Ron

On 08/25/2018 12:44 AM, Adrian Musceac wrote:
Hi Marcus,

You're right about the RTL sample rate, but I'm curious about why it is so 
small.
Is it the bus speed? The ADC is obviously fast enough for DVB-T2.

Regards,
Adrian

On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)" 
 wrote:

Hi Martin,

internally, the RTL dongles are fast enough to capture full DVB-T (not
-T2) channels, and demodulate, and decode them, and deliver the video
stream to the host. However, RTL-SDR can't use that mode - it uses a
"bypass the whole Digital TV specific stuff" mode and directly passes
IQ samples through USB.

In that mode, it simply can't do more than 2 or 3 MS/s (can't
remember), which isn't enough to cover 6 MHz - so everyone's right, you
can basically receive the AM black/white info at a partial bandwidth of
the ca 5 MHz of the luma signal, but you won't get any color
information that way, or audio with the same receiver as you do video.

Cheers,
Marcus

On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:

First, I will talk about the things I know for sure.  The
 NTSC analog system as well as Pal systems in a lot of the rest of
 the world had a lot in common with eachother.  Both systems
 transmitted an AM video signal in Vestigial single sideband mode
 such that the carrier frequency was always about 1.25 MHZ above
 the start of a channel.  NTSC systems in the Americas also
 transmitted an audio carrier in FM which was always 4.9 MHZ above
 the video carrier.  Pal systems used exactly the same type of
 transmissions except that the 625-line video at 25 frames per
 second made a slightly wider spectrum such that the audio and
 video carriers were separated by 5.x MHZ, making each Pal channel
 7 or 8 MHZ wide.

As others have suggested, you could probably get a
 monochrome fuzzy image if you can get your sound card to sample
 fast enough.  You can also decode the mono sound by setting your
 RTL receiver to behave just like a FM broadcast receiver but set
 the frequency to whatever the video carrier frequency is plus 4.5
 MHZ.  if the video carrier is 55.250 MHZ, the audio will be at
 59.75 MHZ.  The deviation is 75 KHZ unlike FM radio which is 150
 KHZ.

That would be a good simple test to see if you are
 receiving the channel at all.

I am guessing that since the RTL chips were designed for
 the European television market for cable and over-the-air
 broadcasts, they can be sampled extremely fast since the digital
 channels still take up the same bandwidth as their analog
 ancestors.

Martin McCormick WB5AGZ

 Anders Hammarquist  writes:

 In a message of Fri, 24 Aug 2018 10:27:40 +0200, "Ralph A. Schmid,
 dk5ras" writes:

 Hi Andres,

 just had a short look: doesn't NTSC use a nearly 6 MHz
 bandwidth?

 Best regards,
 Marcus


 Yes, no way with the RTL to catch NTSC, it does in SDR mode only
 2.smth


 MHz bandwidth.

 Actually, you should be able to get a picture. The horizontal
 resolution
 will be
 about half of what it would be for the full bandwidth, and no
 colour (as
 the colour
 subcarrier at 3.58 MHz is outside the pass band). You want the pass
 band
 of the reciever
 from just below the video carrier and as high as it will go.

 /Anders







___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Adrian Musceac]

Hi Kyeong,
Thanks for all the answers!

Regards,
Adrian

On August 25, 2018 8:31:57 AM UTC, Kyeong Su Shin  wrote:
>Hello Adrian,
>
>
>The USB interface is integrated in the RTL-SDR chip (RTL2832U), so it
>cannot be replaced (as far as I know).
>
>
>In theory, USB 2.0 can support faster data rates (HackRF does 16 MS/s -
>20 MS/s with USB 2.0 8 bit I-Q). As Ron mentioned, it is due to the
>cost reduction.
>
>
>Regards,
>
>Kyeong Su Shin
>
>
>
>보낸 사람: Adrian Musceac  대신 Discuss-gnuradio
>
>보낸 날짜: 2018년 8월 25일 토요일 오후 5:13:09
>받는 사람: discuss-gnuradio@gnu.org; Ron Economos
>제목: Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER
>
>Hi Ron,
>
>So in theory, replacing the USB2 chip with a USB3 would allow access to
>the full sample rate, or is there some other internal limitation?
>
>Regards,
>Adrian
>
>On August 25, 2018 8:06:20 AM UTC, Ron Economos 
>wrote:
>
>The maximum Transport Stream rate of DVB-T is 31.67 Mbps, so the USB
>interface only needs to deliver 4 MB/s. Since you need two 8-bit
>samples in IQ mode, it's 2 Msps.
>
>Ron
>
>On 08/25/2018 12:44 AM, Adrian Musceac wrote:
>Hi Marcus,
>
>You're right about the RTL sample rate, but I'm curious about why it is
>so small.
>Is it the bus speed? The ADC is obviously fast enough for DVB-T2.
>
>Regards,
>Adrian
>
>On August 24, 2018 7:42:17 PM UTC, "Müller, Marcus (CEL)"
> wrote:
>
>Hi Martin,
>
>internally, the RTL dongles are fast enough to capture full DVB-T (not
>-T2) channels, and demodulate, and decode them, and deliver the video
>stream to the host. However, RTL-SDR can't use that mode - it uses a
>"bypass the whole Digital TV specific stuff" mode and directly passes
>IQ samples through USB.
>
>In that mode, it simply can't do more than 2 or 3 MS/s (can't
>remember), which isn't enough to cover 6 MHz - so everyone's right, you
>can basically receive the AM black/white info at a partial bandwidth of
>the ca 5 MHz of the luma signal, but you won't get any color
>information that way, or audio with the same receiver as you do video.
>
>Cheers,
>Marcus
>
>On Fri, 2018-08-24 at 12:22 -0500, Martin McCormick wrote:
>
>First, I will talk about the things I know for sure.  The
> NTSC analog system as well as Pal systems in a lot of the rest of
> the world had a lot in common with eachother.  Both systems
> transmitted an AM video signal in Vestigial single sideband mode
> such that the carrier frequency was always about 1.25 MHZ above
> the start of a channel.  NTSC systems in the Americas also
> transmitted an audio carrier in FM which was always 4.9 MHZ above
> the video carrier.  Pal systems used exactly the same type of
> transmissions except that the 625-line video at 25 frames per
> second made a slightly wider spectrum such that the audio and
> video carriers were separated by 5.x MHZ, making each Pal channel
> 7 or 8 MHZ wide.
>
>As others have suggested, you could probably get a
> monochrome fuzzy image if you can get your sound card to sample
> fast enough.  You can also decode the mono sound by setting your
> RTL receiver to behave just like a FM broadcast receiver but set
> the frequency to whatever the video carrier frequency is plus 4.5
> MHZ.  if the video carrier is 55.250 MHZ, the audio will be at
> 59.75 MHZ.  The deviation is 75 KHZ unlike FM radio which is 150
> KHZ.
>
>That would be a good simple test to see if you are
> receiving the channel at all.
>
>I am guessing that since the RTL chips were designed for
> the European television market for cable and over-the-air
> broadcasts, they can be sampled extremely fast since the digital
> channels still take up the same bandwidth as their analog
> ancestors.
>
>Martin McCormick WB5AGZ
>
> Anders Hammarquist  writes:
>
> In a message of Fri, 24 Aug 2018 10:27:40 +0200, "Ralph A. Schmid,
> dk5ras" writes:
>
> Hi Andres,
>
> just had a short look: doesn't NTSC use a nearly 6 MHz
> bandwidth?
>
> Best regards,
> Marcus
>
>
> Yes, no way with the RTL to catch NTSC, it does in SDR mode only
> 2.smth
>
>
> MHz bandwidth.
>
> Actually, you should be able to get a picture. The horizontal
> resolution
> will be
> about half of what it would be for the full bandwidth, and no
> colour (as
> the colour
> subcarrier at 3.58 MHz is outside the pass band). You want the pass
> band
> of the reciever
> from just below the video carrier and as high as it will go.
>
> /Anders
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Martin McCormick]

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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Andres Campos Santana]

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 
 en nombre de 
Martin McCormick 
Enviado: sábado, 25 de agosto de 2018 18:12
Para: discuss-gnuradio@gnu.org
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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio Info Page - 
lists.gnu.org
lists.gnu.org
Discuss-gnuradio -- GNU Radio, the Free & Open-Source Toolkit for Software 
Radio About Discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio