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
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.
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
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:
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
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
