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

[Tom Rondeau]

On Thu, Jul 23, 2015 at 10:54 AM, Nick Foster <address@hidden> wrote:

My guess, educated only in that I've seen it happen before, is that one of the blocks in your flowgraph exhibits behavior which is dependent on the number of samples per work call. Loading the machine down with GUI blocks will change the number of samples GR doles out during each work call.

Timing synchronizers would be the first place I'd look.

--n

Hey guys,

I just replied to bob wole on another thread with a bug that I think is related to this issue, too. To quote myself:

"The problem isn't with the GUI sinks; you can replace them with null sinks and you get the same problem. It's a race condition in our tag pruning method that was changed in 3.7.6. We have a patch that we're putting in now that will be part of 3.7.8.

The patch goes backwards a bit to how tag pruning was originally done. However, with the map, we no longer have to restart the iterator at begin() like we used to, and we can terminate early, so this should still be much faster than the original."

Hope this solves others' problems as well!

Tom

 

 

On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller <address@hidden> wrote:

Hi Rich,

being really surprised:
I think it would be nice if we knew a bit more about the signal processing part of your flow graph.
What does it rely on? Pure Sample Streams? Stream Tags? Message Passing? Old-Style Message queues?

Best regards,
Marcus

On 22.07.2015 20:11, Richard Bell 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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio