Partial atsc 2.x in use


#1

It turns out to be not too awefully difficult (tho not officially
approved :wink: 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


#2

On Mon, 2006-05-08 at 14:57 -0400, Charles S. wrote:

the chain works, with some room for moving processes
around and optimizing. For instance, the RF gets mixed

Yeah, splitting the resampling/translating block helped.
Just to put things in perspective, we’re getting about
1MB of transport stream every 6 seconds. I think ‘real
time’ takes about 2.5MB/sec (20Mbps) - so were still
taking about 15 minutes to get 1 minute of TV, or 7.5
hours for a 1/2 hour show :wink:

–Chuck


#3

You’re making great progress! Any idea what’s wrong with the 2.0 bit
timing?

Once you get that done we can work on some serious optimization, since
the chain as constituted has a lot of redundancy.

Matt

On Mon, 2006-05-08 at 14:57 -0400, Charles S. wrote:

another cpu, piped to
instead of 8->40->20)


Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Matt E. removed_email_address@domain.invalid