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) <muel...@kit.edu>
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 <arob...@gmail.com> 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) <muel...@kit.edu>
> 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
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
