Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor

[Alex Roberts]

Sure. FYI I'm running 3.7.10....here is the error:

Traceback (most recent call last):
  File "/home/user/gnuradio/dvbt_tx_demo.py", line 384, in <module>
    main()
  File "/home/user/gnuradio/dvbt_tx_demo.py", line 372, in main
    tb = top_block_cls()
  File "/home/user/gnuradio/dvbt_tx_demo.py", line 307, in __init__
    self.connect((self.custom_reed_solomon_dec_0, 1), (self.qtgui_number_sink_0, 0))   
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 47, in wrapped
    func(self, src, src_port, dst, dst_port)
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 110, in connect
    self.primitive_connect(*args)
  File "/usr/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5331, in primitive_connect
    return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
ValueError: port number 1 exceeds max of 0

I connected the nerrors_corrected output (type int) to a qt number sink. If I make the output optional and don't connect to it, I don't get the error.

On Wed, Jul 24, 2019 at 10:38 AM Müller, Marcus (CEL) <address@hidden> wrote:

Hi Alex!
Hm, interesting. Would you happen to have the full verbatim error?

As a complete aside:
I know we're not doing any of that consistently in the tree, but
especially when handling things like polynomials "packed" into
integers, and amounts of bits, I always recommend people explicitly use
"unsigned int", or directly go for an explicitly sized integer type,
e.g. "uint64_t gfpoly" for their polynomial representations, so that
there's no arithmetic surprises – signed integer overflow, for example,
is way less well-defined than unsigned.

Best regards,
Marcus

On Wed, 2019-07-24 at 10:30 -0500, Alex Roberts wrote:
> So I tried re-implementing the gr-dtv Reed Solomon decoder with an additional output so I could monitor/output the number of errors corrected.
> I used gr-modtool, created new block with new name so it wouldn't conflict with the existing and made sure to update the markup language for the grc block.
>
> I get an error about Number of outputs 1 exceed max 0. I'm not sure why that is.
>
> Here is my impl declaration with io_signatures.
>
> custom_reed_solomon_dec_impl::custom_reed_solomon_dec_impl(int p, int m, int gfpoly, int n, int k, int t, int s, int blocks)
>       : block("custom_reed_solomon_dec",
>           io_signature::make(1, 1, sizeof(unsigned char) * blocks * (n - s)),
>           io_signature::make2(1, 2, sizeof(unsigned char) * blocks * (k - s), sizeof(int) )), // Change to make2 to support outputting nerrors_corrected in the general_work() function
>       d_n(n), d_k(k), d_s(s), d_blocks(blocks)
> {
> ...
> }
>
>
> On Tue, Jul 23, 2019 at 3:44 PM Alex Roberts <address@hidden> wrote:
> > Marcus,
> >
> > I think what you said makes sense. I was initially thinking I would have a synchronous block with a message port output, but if I can keep it as simple as a sync block with two outputs just with different sizes, then that is where I will start.
> >
> > Thanks,
> > Alex.
> >
> > On Tue, Jul 23, 2019 at 9:16 AM Müller, Marcus (CEL) <address@hidden> wrote:
> > > Hi Alex,
> > >
> > > to get this straight: on your monitoring output, you get one item of
> > > output per item of input? (an input item being a vector, and a
> > > monitoring output item being a number)
> > >
> > > Then, everything is well: The thing is still a sync block, just one
> > > where not all output item sizes are identical, and not all are
> > > identical to the input item sizes.
> > >
> > > Even if that's not the case, the right way here would be to write a
> > > general block with streams, not an asynchronous messaging block, since
> > > the monitoring data is "synchronous" to the other data.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2019-07-23 at 09:10 -0500, Alex Roberts wrote:
> > > > I'd like to monitor an internal variable on a DSP block. have not made a custom block before but have read through some tutorials.
> > > >
> > > > Since the DSP inputs and outputs are vectors, and the variable is a single item whose value is dependent on the processing of the vector, the number of outputs does not match the number of inputs. The value is updated after each input vector is processed. Does this mean I should use the message port to asynchronously output the variable, or can I simply add another port and output the value as say a float or integer that is synchronously updated with the block?
> > > >
> > > > For example, in a Reed-Solomon implementation, how could I add an output to monitor the number of errors corrected?
> > > > _______________________________________________
> > > > 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