Re: [Discuss-gnuradio] benchmark_loopback.py in discontinuous mode results in transmission errors

[Tom Rondeau]

On Wed, Dec 15, 2010 at 6:24 PM, Kyle Zhou <address@hidden> wrote:
> I am playing with benchmark_loopback.py.
> For continuous mode, it seems ok except the first packet is erroneous, which
> I assume is due to initial state of the receiver.
>
> But for discontinuous mode, I found most of the packets are in errors.
>
> I used default values for all parameters.
>
> Does that mean the demod cannot synchronize to the received signal quickly
> enough? So for each burst of 5 packets, the first few packets are incorrect
> due to slow synchronization?

Yes, that should be the cause.

> However, according to the output, the error pattern seems random, not
> necessary the first few of each burst.

Must not be settling at all, then. Not sure why since it should settle
after missing maybe the first packet.

> I tried benchmark_qt_loopback2.py, which hangs up after transmitting 5
> packets (dead lock?)

I don't think I've ever tried the bursty mode. I know the FLL loop is
a bit slow to converge, so I'm not surprised this doesn't work in
bursty mode. It should work in continuous mode fine, though. I run it
all the time that way.

> This really confuses me. Is it bug or something else?
>
> Kyle

It's probably not a "bug" in the classic programming sense of the
word, but just not a perfect implementation bug. Needs work; I hope to
get back to it...

Tom