Re: ATSC decoding

Tom R. [email protected] 04/20/10 9:58 AM >>>
On Mon, Apr 19, 2010 at 8:12 PM, Stephen B. [email protected]
wrote:

We followed the instructions in ./gnuradio/gr-atsc/src/python/README to no success.

Using the FFT we found 507.25M to have a strong signal.
According to http://en.wikipedia.org/wiki/North_American_broadcast_television_frequencies#UHF_band this is channel 20.
And according to http://www.fcc.gov/fcc-bin/tvq?state=AL&call=&arn=&city=&chan=14&cha2=69&serv=&type=0&facid=&list=2&dist=&dlat2=&mlat2=&slat2=&dlon2=&mlon2=&slon2=&size=9 this is WCOV from Montgomery, Alabama.
So we do have the correct video carrier frequency, which I assume is the frequency we want to record and decode into a video.

Question #1) Is the video carrier the one that carriers the video, or would it be the ATSC carrier?

If it’s ATSC, you should see a very strong carrier with a very small
lump of energy to the left of it (this is the vestigial sideband) and
a large, fairly flat signal to the right that rolls off. This likely
won’t be flat due to fading, but you should be able to recognize it as
a 6 MHz chunk of spectrum being occupied. You probably already know
this, but I’m pointing it out to help distinguish between the ATSC
carrier and video carrier. In NTSC, there were a few different
carriers while in ATSC there’s just the one big guy.

And you want to use the ATSC carrier. This wikipedia article gives you
the frequencies:

For the channel you’re looking at (20), the carrier would be at 507.31
MHz. There’s a PLL to lock to the carrier, but I’m not sure if it’s
broad enough to handle the 60 kHz offset you’re using. This could be
the cause of your problem.

In general, you should be able to output the different stages to files
by editing the Python code and take a look at different stages to see
what’s going on. This might help identify where the problem is.

Tom

The output file, ‘test.mpeg’ is empty.

Question #2) What do we need to fix to get /tmp/atsc_pipe_5 to fill.
Question #3) What do we need to fix to get temp.mpeg to fill.

Thank you,
Bobby Black & Stephen B.
Auburn University
[email protected]
(334) 804-4826

Thanks Tom,

Just for clarification:

You said:

“For the channel you’re looking at (20), the carrier would be at 507.31
MHz. There’s a PLL to lock to the carrier, but I’m not sure if it’s
broad enough to handle the 60 kHz offset you’re using. This could be
the cause of your problem.”

What exactly do you mean by a 60kHz offset?
We’re not sure where we are using such an offset.
Are there alternatives to how we’re doing this that may yield better
results?

Thanks again,

Auburn University Senior Design Team: Software Group
Stephen B. and Bobby Black
[email protected]
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs