Hi all,
I did some investigations regarding the zero output problem: First of
all I installed gnuradio 0.9 on an old Red Hat 9 installation and made
tests with the files from http://comsec.com/data/README. As the 0.9 ATSC
DTV decoder works fine, I took the intermediate save files (*.rxout, can
be obtained when using the log function) and used them as input for the
version 3.x ATSC decoder.
It turned out that everything works fine if I use the 0.9 output after
the bit timing loop (bt_*.rxout) as input for the 3.x frame sync block.
Further, if I use the 0.9 fpll output as input for the 3.x bit timing
loop nothing happens (zero output). So I guess the problem can be
isolated to the bit timing loop.
I still do not fully understand the code, so I hope someone can help me
to further isolate the problem. If we can fix this we would finally have
a working gnuradio ATSC receiver again!
Regards
Klaus
-Ursprüngliche Nachricht-
Von: discuss-gnuradio-bounces+klaus.hueske=tu-dortmund...@gnu.org
[mailto:discuss-gnuradio-bounces+klaus.hueske=tu-dortmund...@gnu.org] Im
Auftrag von Klaus Hueske
Gesendet: Donnerstag, 24. Juni 2010 09:52
An: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] ATSC decoding
Hi Stephen,
Did you make progress with this zero byte output problem? Anyway, I'm
wondering if the ATSC receiver implementation will work at all with the
current version of Gnuradio. It looks like parts of the original ATSC
implementation that was working with Gnuradio 0.9 have been adapted to
be used in Gnuradio 2.0, but now we have 3.2.2. Anyone here who can
verify that the provided code can decode ATSC signals? Thanks Klaus
---
On Mon, Apr 19, 2010 at 8:12 PM, Stephen Branch 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_freque
ncie
s#UHF_band
> this is channel 20.
>And according to
>http://www.fcc.gov/fcc-bin/tvq?state=AL&call=&arn=&city=&chan=14&cha2=6
9&se
rv=&type=0&facid=&list=2&dist=&dlat2=&mlat2=&slat2=&dlon2=&mlon2=&slon2=
&siz
e=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 Branch
>addr...@hidden (please do not blank out this email)
>black85 @ auburn . edu
>
>Bobby Black
>Auburn University
>addr...@hidden
>(334) 804-4826
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
