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