Benchmark_loopback.py in discontinuous mode results in transmission errors

GNU Radio
1

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?
However, according to the output, the error pattern seems random, not
necessary the first few of each burst.

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

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

Kyle

2

On Wed, Dec 15, 2010 at 6:24 PM, Kyle Z. [email protected] wrote:

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