Effect of samples_per_symbol on benchmark_qt_loopback2.py

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

On Tue, Dec 7, 2010 at 12:42 AM, Ben R. [email protected] wrote:

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

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

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 4:55 PM, Ben R. [email protected] wrote:

Cheers,
Ben

Good to know. That makes sense. The FLL loop is the most sensitive to
the gain parameters. If it’s too high, it never settles and if it’s
too low, it will take to long to onto bursty signals.

Thanks.

Tom