Re: [Discuss-gnuradio] QT Blocks causing BER errors?

[Tom Rondeau]

On Wed, Jul 22, 2015 at 2:11 PM, Richard Bell <address@hidden> wrote:

I've come across a really unexpected correlation this morning that I'm hoping someone has an explanation for. I have a large flow graph with many QT GUI blocks because I'm debugging a design. Mostly Time Sinks and Constellations plots with a couple of Frequency Sinks thrown in. The number of points in some of the time sinks is rather large, on the order of 30k, which allows me to see several packets of data at once.

What I noticed this morning, while debugging a BPSK loopback BER tester, is by disabling a number of Constellation plots which were fed by RRC filters to make the plot pretty, errors went away. The system works as you would expect a simulation with no noise or channel effects to work, perfectly. When I enable those GUI blocks, the system looses packet synchronization within the first minute consistently. Nothing is changed in the data stream between these tests.

So the question is, is there a known cap on GUI plots? Like I said, I have a lot of them and some of them are plotting a large number of points. Could this be causing buffers overruns into data spaces or something scary like that?

Another thought I had, could there be an identity problem in which GNU Radio at some point can't uniquely identify blocks with the same name apart from each other and thus chooses one in some default manner? I'm imagining a plotting stream getting crossed with a data stream in some way.

The bottom line is all I need to do to make this system work is disable some plotting only related blocks. Is there a known plotting cap issue that I should be aware of?

Thanks,

Rich

Rich,

That is really surprising. As sinks, those blocks shouldn't be affecting anything in the data stream at all. They might back up the flow of the system if things are running too hard on your processor, but you said you were running a loopback test, so there shouldn't be any hardware I/O causing problems.

I'm not sure what to make of this right now.

Tom