discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] partial atsc 2.x in use


From: Charles Swiger
Subject: [Discuss-gnuradio] partial atsc 2.x in use
Date: Mon, 08 May 2006 14:57:46 -0400

It turns out to be not too awefully difficult (tho not officially
approved ;)   to modify the gnuradio-0.9 atsc code to use a subset
of blocks, specifically everything from bit-timing-loop to
field-sync-demux (float in, soft-data-segments out).   So here's
what I have working across 4 cpu's:

Start with 8Msps complex with signal centered on 0Hz
using usrp_rx_cfile.py to collect data.

Then simultaneously running:

1) One fully 2.x module upsamples to 20Msps and translates
to 5.75Mhz center float, using 99% of one cpu - this is the
bottleneck - piped to:

2) A fully 2.x module with root-raised-cosine filter (taps
calculated in python using the 0.9 filter method), the ported
(formerly 0.9) FPLL, and remove-DC (iir), using about 60%
of another cpu, piped to:

3) the old 0.9 bit-timing thru fs-demux code, about 55% of
another cpu, piped to

4) The 2.x Viterbi, Deinterleaver, Reed-Soloman decoder
and de-randomizer, about 20% of the 4th cpu.


It took some hacking on packet padding and de-padding but
the chain works, with some room for moving processes
around and optimizing. For instance, the RF gets mixed
and translated twice. A complex FPLL could handle that
in one step using, say, a more convenient 16Msps (8->16,
instead of 8->40->20)

Earlier the busiest cpu was only at 60% - switching from
Samba to NFS (the rf datafiles are on another machine) 
moved the bottleneck off the network disk sharing to the
resampler module.

--Chuck






reply via email to

[Prev in Thread] Current Thread [Next in Thread]