[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] benchmark_loopback.py in discontinuous mode resul
Re: [Discuss-gnuradio] benchmark_loopback.py in discontinuous mode results in transmission errors
Wed, 15 Dec 2010 19:54:53 -0500
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?
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...