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

[Tom Rondeau]

On Wed, Dec 8, 2010 at 4:55 PM, Ben Reynwar <address@hidden> wrote:
> 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

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




> 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
>>>
>>
>