Re: [Discuss-gnuradio] ATSC decoding

[Tom Rondeau]

On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch <address@hidden> wrote:
> 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 
> 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:
http://en.wikipedia.org/wiki/Television_channel_frequencies#Americas_.28most_countries.29.2C_South_Korea.2C_Taiwan_and_the_Philippines

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


> 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 Branch
> address@hidden (please do not blank out this email)
> black85 @ auburn . edu
>
> Bobby Black
> Auburn University
> address@hidden
> (334) 804-4826