In case anyone else happens to be interested, it appears that you need a lower value of freq_alpha for the frequency lock loop (fll_band_edge_cc) if the number of samples per symbol is higher. I'm pretty sure that an unstable fll was causing the errors I was seeing.
python benchmark_qt_loopback2.py --samples-per-symbol 11 produces lots of errors and lost packets python benchmark_qt_loopback2.py --samples-per-symbol 11 --freq-alpha 0.005 works fine (default freq-alpha is 0.01) Cheers, Ben On Wed, Dec 8, 2010 at 7:10 AM, Ben Reynwar <[email protected]> wrote: > I was using that many so I could see how it all worked better (plots > with two samples per symbol are a little less intuitive to look at). > I realize it's not of practical importance but I thought it was > interesting. > > Cheers, > Ben > > On Tue, Dec 7, 2010 at 9:27 PM, Tom Rondeau <[email protected]> wrote: >> On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <[email protected]> wrote: >>> When I run >>> gnuradio/gnuradio-examples/python/digital/benchmark_qt_loopback2.py >>> I get a strange dependence on samples_per_symbol. >>> >>> I would naively have expected that the more samples per symbol the >>> better, however: >>> >>> python benchmark_qt_loopback2.py --samples_per_symbol 10 >>> produces no errors >>> >>> whereas >>> python benchmark_qt_loopback2.py --samples_per_symbol 11 >>> produces lots of errors >>> >>> Does anyone have any idea what's going on here? >>> >>> Cheers, >>> Ben >> >> That's a very large number of samples per symbol. I know I tested up >> to 10, but more than that's pretty excessive. Ok, more than 2 is >> excessive, really. Off the top of my head, I can't think of exactly >> what might be going wrong here, but you should really never need to >> use that many samples per symbol, anyway. >> >> Tom >> > _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
