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: Tom Rondeau
Subject: Re: [Discuss-gnuradio] QT GUI Bercurve Sink - confusion about number of block ports
Date: Thu, 10 Mar 2016 09:59:33 -0500

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


reply via email to

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