On Wed, Dec 15, 2010 at 6:24 PM, Kyle Zhou <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
