Re: [Discuss-gnuradio] Effect of samples_per_symbol on benchmark_qt_loopback2.py

[Ben Reynwar]

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 <address@hidden> 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 <address@hidden> wrote:
>> On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <address@hidden> 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
>>
>