Forum: GNU Radio atsc speed boost

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Charles S. (Guest)
on 2006-05-17 23:56
(Received via mailing list)
This works a bit more effeciently in matching a usrp to the atsc code
(either all 0.9, or part 0.9 and part 2.x):

Instead of: collect data with usrp decim = 8, then interp by 5 (8Msps
to 40) then decim by 2 (40Msps to 20) while upshifting to 5.75MHz -

just collect data with decim = 10, then interp by 3 (6.4Msps to
19.2Msps), then upshift.   The 0.9 code need two changes, one to
atsc_rx.cc, set input_rate to 19.2e6 (IR_20 = 19.2 instead of 20e6), and
there is also needed a little tweak in GrBitTimingLoop3.cc and
atsc_sssr.cc to get  past the sanity checks for ratio of receiver clock
to symbol rate, change the 1.8 to 1.78, it's *just* under the limit ;)
( 19.2 / 10.76 ).

This puts the bottleneck back on the modified lt-atsc_rx process, which
includes bit_timing_loop, fs_checker, equalizer and field_sync_demux. I
should be able to split those up and manually redistribute the load
a little better still.

With that it's up from 1MiB / 6 seconds to about 1.2 or 1.3, or at least
20% faster, plus it takes 20% less disk space recording the signal
( before, a two hour movie would *just* fit on two striped 220GB disks
using decim=8, with 5GB left ;)

--Chuck
Charles S. (Guest)
on 2006-05-18 00:25
(Received via mailing list)
On Wed, 2006-05-17 at 15:52 -0400, Charles S. wrote:

> just collect data with decim = 10, then interp by 3 (6.4Msps to
> 19.2Msps), then upshift.   The 0.9 code need two changes, one to

Some more fat can be squeezed out of the pipeline if the 'upshift
to 5.75MHz' and FPLL could be combined. Both are in the gr2 realm,
but as it is, the FPLL is just a 2.0 wrapper on the old code, which
takes float in/out so the spectrum has to be all real positive
frequencies. A complex version that can take a pilot freq of -2.69Mhz
I think would help. It would also eliminate the need for a mixer image
lp filter.

--Chuck
Eric B. (Guest)
on 2006-05-19 04:59
(Received via mailing list)
On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote:
> I think would help. It would also eliminate the need for a mixer image
> lp filter.
>
> --Chuck

Now you're getting closer.  If you start with the complex baseband
from the USRP, and rework the FPLL so that it works with complex
input, you can get rid of a bunch more ;)

Eric
Charles S. (Guest)
on 2006-05-19 19:22
(Received via mailing list)
On Thu, 2006-05-18 at 17:56 -0700, Eric B. wrote:
> On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote:
> > On Wed, 2006-05-17 at 15:52 -0400, Charles S. wrote:
> >
> > > just collect data with decim = 10, then interp by 3 (6.4Msps to
> > > 19.2Msps), then upshift.   The 0.9 code need two changes, one to
> >
> > Some more fat can be squeezed out of the pipeline if the 'upshift
> > to 5.75MHz' and FPLL could be combined. Both are in the gr2 realm,

> Now you're getting closer.  If you start with the complex baseband
> from the USRP, and rework the FPLL so that it works with complex
> input, you can get rid of a bunch more ;)
>

Well, at this point I'm pretty much stuck as I'm:

1) unable to port the bit-timing to fs-demux chain - eyes glaze over,
just don't understand everything going on to finish the job,
particularly how to deal with inputs[0].index in the 2.x framework, and

2) no luck breaking up the 0.9 bt to fs-demux, more involved
mucking around the old code would be required (which we want to avoid)

So at this point that streach of code takes up the most cpu and
no further optimizing is possible untill that is resolved, only
using 3/4 of all available cpu.

--Chuck
This topic is locked and can not be replied to.