discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] QT GUI Bercurve Sink - confusion about number of


From: Tracie Perez
Subject: Re: [Discuss-gnuradio] QT GUI Bercurve Sink - confusion about number of block ports
Date: Thu, 17 Mar 2016 19:51:47 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/10/2016 08:59 AM, Tom Rondeau wrote:
On Wed, Mar 9, 2016 at 3:24 PM, Tracie Perez <address@hidden> wrote:
Hi all,

If I open a new flow graph in GRC and select a QT GUI Bercurve Sink block, the default parameters create 16 ports (connections) on the block. The default in the "Num Curves" field is 1 and the default in the "esno" field is numpy.arange(0.0, 4.0, .5), which is 8 values. I'm not sure why there are 16 ports.

If you then change "Num Curves" to 2, the number of ports on the block changes to 32. Also, if you change the value of "esno" to a different range of values, it changes the number of ports. Is that on purpose? Should the specified number of esno values be related to the number of ports?

I would expect that the number of ports on this block is simply equal to the number of curves specified. i.e., 2 in the "num curves" field generates 2 ports on the block.

In fact, that is the behavior of the ber_curve_gen.grc example. However if you start from a new flowgraph, there's a different behavior.

Any clarification on this would be appreciated. I'm working with GNU Radio v. 3.7.9.1.

Thanks,
tracie


Tracie,

Yes, this is pretty confusing. It's due to the fact that this block calculates the BER itself internally by comparing the original data (pre-distortion) from input i with the post-distortion and post-decoding data on input i+1. So input_items[i] ^ input_items[i+1] is the BER to plot for that particular Es/N0 point.

This matches up to the behavior of a BER Curve Generator block (look at gr-fec/python/fec/bercurve_generator.py and gr-fec/python/fec/fec_test.py).

It might make more sense from a simulation point of view to have something like the 0th input be the original data and inputs 1 to N be the N encoder/decoder pairs we are comparing. But the way it currently is allows each encoder/decoder pair to operate off completely independent streams.

Does that clear things up? Perhaps we can put this explanation into the manual.

Tom


Tom,

Thanks very much for the quick reply, and a big congrats on your new position at DARPA!

From your explanation, I think I understand how these connections are being made internally, and why there are so many, allowing for many independent "internal flowgraphs" to be running at the same time. It's clearer when looking at the python flow graph script too.

However, my original confusion was due to forgetting something much more basic. I'm going to leave this here so maybe it will help someone in the future:

By default, when you select a "BER Curve Gen." block and a "QT GUI Bercurve Sink" block in GRC, they're going to appear to have a type mismatch on the ports, because only one is "bussified." One way to fix this is to right click on the QT GUI Bercurve Sink block. Select "More," then select "Toggle Sink Bus." Boom, now you can connect a BER Curve Gen block to each port on the Bercurve sink. There number of busports [1] on the Bercurve sink block will now equal the "num curves" you've specified for that block.

~ tracie

[1] gnuradio.org/redmine/projects/gnuradio/wiki/Busports

reply via email to

[Prev in Thread] Current Thread [Next in Thread]