Forum: GNU Radio partial atsc 2.x in use

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Charles S. (Guest)
on 2006-05-08 22:59
(Received via mailing list)
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 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.

Charles S. (Guest)
on 2006-05-08 23:20
(Received via mailing list)
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 ;)

Matt E. (Guest)
on 2006-05-10 10:04
(Received via mailing list)
You're making great progress!  Any idea what's wrong with the 2.0 bit

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


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
Matt E. <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.