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