Re: [Discuss-gnuradio] Problem building gr-display
Barry, Try this: git clone https://github.com/dl1ksv/gr-display.git cd gr-display git checkout gnuradio3.8 -cp From: Discuss-gnuradio on behalf of Barry Duggan Sent: Wednesday, July 24, 2019 3:47 PM To: Volker Schroer Cc: Discuss Gnuradio Subject: Re: [Discuss-gnuradio] Problem building gr-display Hi Volker, 1) What specific URL should I use? I tried: git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8 Cloning into 'gnuradio3.8'... fatal: repository 'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found and also: git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display 2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If so, what is the path? Thanks, -- Barry Duggan KV4FV On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote: On github in gr-display exists a gnuradio3.8 branch. Try this one. Now that gnuradio switched to 3.8 I should switch the master branch to 3.8, too. ___ 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
Re: [Discuss-gnuradio] Problem building gr-display
Hi Volker, 1) What specific URL should I use? I tried: git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8 Cloning into 'gnuradio3.8'... fatal: repository 'https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/' not found and also: git clone https://github.com/dl1ksv/gr-display/tree/gnuradio3.8/gr-display 2) Does the cmake command need to define GNURADIO_MODULE_DIRECTORY? If so, what is the path? Thanks, -- Barry Duggan KV4FV On Wed, 24 Jul 2019 16:30:02 +0200, Volker Schroer wrote: On github in gr-display exists a gnuradio3.8 branch. Try this one. Now that gnuradio switched to 3.8 I should switch the master branch to 3.8, too. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Hi,
I think it is very possible to merge them, specially in the RS decoder
which I didn't modify much. The viterbi took me quiet some thinking and
testing, but it's possible too.
If it would make sense, that's another question :-). I use it mostly as
another indicator that the flowgraph is correctly configured (sometimes the
constellation is good enough, but if you have misspecified for instance the
time interleaver length you will get garbage). Performance-wise it has
negligible impact.
If you are interested I can try to make a couple of PRs.
best
El mié., 24 jul. 2019 a las 14:21, Müller, Marcus (CEL) ()
escribió:
> Hi Federico,
>
> would it make sense to merge that extension back to mainline GNU Radio?
>
> Best regards,
> Marcus
> On Wed, 2019-07-24 at 12:41 -0300, Federico 'Larroca' La Rocca wrote:
> > Hi,
> > If you are interested in measuring the number of errors in the
> Reed-Solomon block of DTV, you may take a look at our OOT module gr-isdbt (
> https://github.com/git-artes/gr-isdbt) which includes modifications to
> the RS (and the viterbi) decoder to outputs the BER (but is easily
> modifiable to output the number of errors).
> > best
> > Federico
> >
> > El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) (<
> muel...@kit.edu>) escribió:
> > > 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
> 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 intege
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Wow, that's a pretty old version GNU Radio! Might be worth updating
your Linux distro :)
Anyways, this is strange!
You don't happen to implement a `check_topology` method, do you?
Best regards,
Marcus
On Wed, 2019-07-24 at 10:55 -0500, Alex Roberts wrote:
> Sure. FYI I'm running 3.7.10here is the error:
>
> Traceback (most recent call last):
> File "/home/user/gnuradio/dvbt_tx_demo.py", line 384, in
> 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) 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 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)
> > > > 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 th
Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error
Hi Michael,
Any update on this? I downgraded my install of uhd and gnuradio as follows
but I have the same error.
Traceback (most recent call last):
File "/home/sumit/Desktop/top_block.py", line 122, in
main()
File "/home/sumit/Desktop/top_block.py", line 110, in main
tb = top_block_cls()
File "/home/sumit/Desktop/top_block.py", line 78, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'
sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
*UHD_3.14.1.HEAD-0-g5491b80e*
--
-- UHD Device 0
--
Device Address:
serial: 317DD1E
addr: 192.168.10.2
fpga: HG
name:
product: X310
type: x300
sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version
*GNU Radio Companion 3.7.13.5*
This program is part of GNU Radio
GRC comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it.
sumit@PP0380:~/gradio/src/gnuradio$ git status
On branch maint-3.7
*Your branch is up to date with 'origin/maint-3.7'.*
Regards
Sumit
On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens
wrote:
> I guess for your need so long as it works that's what matters, yes?
>
> We'll work on fixing the issue you found anyway ... seems like it's legit
> & undesirable LOL.
>
> Good luck with your demo! - MLD
>
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>
> Well it worked after compiling old checkouts (but not giving me the usual
> satisfaction of a fresh install... but anyways)
>
> On Thu, 27 Jun 2019 at 19:45, sumit kumar wrote:
>
> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>
--
--
Sumit kumar
Postdoc
SnT, Luxembourg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Hi Federico,
would it make sense to merge that extension back to mainline GNU Radio?
Best regards,
Marcus
On Wed, 2019-07-24 at 12:41 -0300, Federico 'Larroca' La Rocca wrote:
> Hi,
> If you are interested in measuring the number of errors in the Reed-Solomon
> block of DTV, you may take a look at our OOT module gr-isdbt
> (https://github.com/git-artes/gr-isdbt) which includes modifications to the
> RS (and the viterbi) decoder to outputs the BER (but is easily modifiable to
> output the number of errors).
> best
> Federico
>
> El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) ()
> escribió:
> > 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 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)
> > > > 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
> > __
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Hi,
If you are interested in measuring the number of errors in the Reed-Solomon
block of DTV, you may take a look at our OOT module gr-isdbt (
https://github.com/git-artes/gr-isdbt) which includes modifications to the
RS (and the viterbi) decoder to outputs the BER (but is easily modifiable
to output the number of errors).
best
Federico
El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) ()
escribió:
> 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 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)
> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
Sure. FYI I'm running 3.7.10here is the error:
Traceback (most recent call last):
File "/home/user/gnuradio/dvbt_tx_demo.py", line 384, in
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)
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 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)
> 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-gnura
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
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 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)
> > 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
smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor
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 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)
> 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
Re: [Discuss-gnuradio] Problem building gr-display
On github in gr-display exists a gnuradio3.8 branch. Try this one. Now that gnuradio switched to 3.8 I should switch the master branch to 3.8, too. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem building gr-display
Now that I have GR 3.8 built and running, I tried to build gr-display.
from the README instructions:
"""
get the latest code from https://github.com/dl1ksv/gr-display
The build process is cmake based. So change to the code directory.
There
$mkdir build
$cd build
$cmake -DCMAKE_INSTALL_PREFIX= ../
"""
When I did the cmake, I got:
"""
pi@raspberrypi:~/gr-display/build $ cmake
-DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release ../
-- Modules found in /usr/local/lib/cmake/gnuradio
-- Boost version: 1.67.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- Checking for module 'gmp'
-- No package 'gmp' found
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY
MPIR_INCLUDE_DIR)
-- User set python executable /usr/bin/python3
CMake Error at CMakeLists.txt:102 (message):
GnuRadio Runtime required to compile display
-- Configuring incomplete, errors occurred!
See also "/home/pi/gr-display/build/CMakeFiles/CMakeOutput.log".
""
from CMakeLists.txt:
"""
# Make sure to find the appropriate gnuradio installition if more than
# one installation of gnuradio exists
find_package(Gnuradio "3.8" REQUIRED PATHS ${CMAKE_INSTALL_PREFIX}
${GNURADIO_MODULE_DIRECTORY})
if(NOT GNURADIO_RUNTIME_FOUND)
message(FATAL_ERROR "GnuRadio Runtime required to compile display")
endif()
"""
I have tried:
cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release
-DGNURADIO_MODULE_DIRECTORY="/usr/local" ../
cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release
-DGNURADIO_MODULE_DIRECTORY="/usr/local/bin" ../
cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release
-DGNURADIO_MODULE_DIRECTORY="/usr/local/lib" ../
cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release
-DGNURADIO_MODULE_DIRECTORY="/usr/local/lib/cmake/gnuradio" ../
cmake -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release
-DGNURADIO_MODULE_DIRECTORY="/usr/local/include/gnuradio" ../
but none of them worked.
What do I need for GNURADIO_MODULE_DIRECTORY?
As always, your help is appreciated greatly.
--
Barry Duggan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Underrun when transmitting long packets
Hello all,
I am transmitting TAP packets using USRP E310 in network mode. I have a
custom block called "rtag" which gets two TAP interface inputs and puts
these messages to output (it's serializing these inputs). I am tagging
each packet with "packet_len"(beginning of packet) and "tx_eob"(end of
packet). This is a general_block. It receives a message for detecting
which input has a tagged stream data. According to this message, it
configures its forecast() method.
There is no problem by transmitting short packets. But when i send long
packet to USRP it gives "U" letter. There is a log in below:
--
Tag Debug: TX_OFDM_TAP0
Input Stream: 00
Offset: 100290 Source: n/a Key: packet_len Value: 1950
--
ninput_items: 1950
input[0]: ninput_items[]: 1950, nitems_read(): 100290, noutput_items: 1024
ninput_items[!i]: 0current direction: 0next direction: 100
--
Tag Debug: TX_OFDM_FINAL
Input Stream: 00
Offset: 208330 Source: n/a Key: packet_len Value: 1950
Offset: 210279 Source: rtag Key: tx_eob Value: #t
--
--
Tag Debug: TX_OFDM_TAP0
Input Stream: 00
Offset: 102240 Source: n/a Key: packet_len Value: 8670
--
ninput_items: 1950
input[0]: ninput_items[]: 8670, nitems_read(): 102240, noutput_items: 4096
ninput_items[!i]: 0current direction: 0next direction: 100
--
Tag Debug: TX_OFDM_FINAL
Input Stream: 00
Offset: 212230 Source: n/a Key: packet_len Value: 8670
--
U
--
As you can observe, after sending packet with size of 8670 items, it
prints "U" and this packet cannot transmit to other side.
Another point is, in "TX_OFDM_FINAL" tag debug, i cannot see "tx_eob"
tag. I guess full packet cannot be transmitted to the output by gnuradio.
What is the problem in here?
There is a FG and impl.cc code of my custom block "rtag" in the attachments.
Best regards.
Tue Jun 25 20:14:15 2019
options
author
window_size
2000,2000
category
[GRC Hier Blocks]
comment
description
_enabled
True
_coordinate
(8, 8)
_rotation
0
generate_options
no_gui
hier_block_src_path
.:
id
ofdm_rtag_test
max_nouts
3
qt_qss_theme
realtime_scheduling
run_command
{python} -u {filename}
run_options
prompt
run
True
sizing_mode
fixed
thread_safe_setters
title
placement
(0,0)
variable
comment
_enabled
True
_coordinate
(1224, 36)
_rotation
0
id
decimation
value
1
variable
comment
_enabled
True
_coordinate
(712, 84)
_rotation
0
id
fft_len
value
128
variable
comment
_enabled
1
_coordinate
(104, 244)
_rotation
0
id
filter_frac
value
3
variable
comment
_enabled
True
_coordinate
(272, 140)
_rotation
0
id
fir
value
firdes.low_pass_2(1, samp_rate, (samp_rate/4)+filter_frac, 5000, 100,firdes.WIN_BLACKMAN_HARRIS)
variable
comment
_enabled
True
_coordinate
(1128, 36)
_rotation
0
id
interpolation
value
2
variable
comment
_enabled
0
_coordinate
(224, 212)
_rotation
0
id
ip
value
"addr=192.168.0.12"
variable
comment
_enabled
1
_coordinate
(456, 140)
_rotation
0
id
ip
