On 03/10/2016 08:59 AM, Tom Rondeau wrote:
On Wed, Mar 9, 2016 at 3:24 PM, Tracie Perez
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
