ATSC decoding

GNU Radio
1

Hello everyone,

I am part of Auburn University’s Software Defined Radio Senior Design
team,

Software being used:
Ubuntu v.9.10 on xfs partition
GNURadio v.3.3 (git)
Xine

Available hardware: USRP1, USRP2, WBX daughterboard, TVRX daughterboard

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

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?

We then used:
./usrp_rx_cfile.py -s -d 10 -g 20 -f 507.25e6 atsc_data_6-4m_complex
./interp_short.py atsc_data_6-4m_complex
./xlate.py
./fpll.py
./btl-fsd.py
./viterbi-out.py test.mpeg

Problems:
/tmp/atsc_pipe_5 never fills with data.
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.
[email protected] (please do not blank out this email)
black85 @ auburn . edu

Bobby Black
Auburn University
[email protected]
(334) 804-4826

2

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 Pan-American television frequencies - Wikipedia 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

3

On Wed, Apr 21, 2010 at 3:48 PM, Stephen B. [email protected]
wrote:

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?

You said you were looking for a carrier at 507.25 MHz. I said the
carrier is at 507.31 MHz. That’s a 60 kHz offset.

Tom