Partial atsc 2.x in use

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

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

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
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Matt E. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs