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

Reply via email to