Re: [Discuss-gnuradio] atsc speed boost
On Thu, 2006-05-18 at 17:56 -0700, Eric Blossom wrote: > On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote: > > On Wed, 2006-05-17 at 15:52 -0400, Charles Swiger 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc speed boost
On Wed, May 17, 2006 at 04:22:09PM -0400, Chuck Swiger wrote: > On Wed, 2006-05-17 at 15:52 -0400, Charles Swiger 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 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] atsc speed boost
On Wed, 2006-05-17 at 15:52 -0400, Charles Swiger 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] atsc speed boost
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio