On Wed, Dec 8, 2010 at 4:55 PM, Ben Reynwar 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 causi
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.p
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 wrote:
> On Tue, Dec 7, 2
On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar 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
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
