C++ gnuradio apps

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data – so I don’t need the USRP.

With the new top_block stuff we should be ready for this now, correct?
Here’s a short program towards going down that path:

#include <gr_runtime_types.h>
#include <gr_top_block.h>
#include <gr_null_source.h>
#include <gr_null_sink.h>

int main()
{
gr_top_block_sptr tb = gr_make_top_block(“topblock”);
tb->connect(gr_make_null_source(sizeof(gr_complex)),
gr_make_null_sink(sizeof(gr_complex)));
tb->run();
}

A few questions/observations:

  1. Since most blocks don’t have public constructors, we have to indirect
    through the make friend functions. Is this what we want?

  2. This example doesn’t compile. There are two candidates for connect:

/usr/local/include/gnuradio/gr_hier_block2.h:61: note: candidates are:
void gr_hier_block2::connect(gr_basic_block_sptr)
/usr/local/include/gnuradio/gr_hier_block2.h:64: note:
void gr_hier_block2::connect(gr_basic_block_sptr, int,
gr_basic_block_sptr, int)

What does the first one do?? It only takes a single block…

The second one is presumably with ports? I will try that next. Can we
add a connect method that takes two blocks and assumes the ports are
both 0?

Thoughts? Thanks,

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvv94y9GYuuMoUJ4RAiV4AJ9VRjbz8dxiOPmqJh4ETZjuxiLhpQCgwd0Y
CdXVyDwdj1zHJxOhuhrM6Dw=
=oV3h
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan H. wrote:

Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data – so I don’t need the USRP.

Another observation: It looks like right now there’s no
super-header-file like “gr.h” that does the same thing for C++ that
“import gr” does for Python. This would also be useful :).

Also, from my code it looks pretty straightforward that we should be
able to integrate this with GRC.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvwTcy9GYuuMoUJ4RAq8uAJwJk2+F13mM3bCy4sTUdEuDqjQoMgCffoUC
fR/QiSvjQFdqvSttRdCEC9g=
=T/pr
-----END PGP SIGNATURE-----

On 2/22/08, Dan H. [email protected] wrote:

Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data – so I don’t need the USRP.

With the new top_block stuff we should be ready for this now, correct?

Yep. There is actually a C++ only example in the trunk that is the
equivalent of the canonical dial_tone.py example. It isn’t set to
compile by default, you have to edit some Makefile.am files.

  1. Since most blocks don’t have public constructors, we have to indirect
    through the make friend functions. Is this what we want?

Yes. It’s not very pretty, and we’ve been hiding this in Python by
converting:

gr.null_source(…) --> gr_make_null_source(…)

But the use of these factory functions to return smart pointers is so
beneficial it’s worth the ugliness.

  1. This example doesn’t compile. There are two candidates for connect:

/usr/local/include/gnuradio/gr_hier_block2.h:61: note: candidates are:
void gr_hier_block2::connect(gr_basic_block_sptr)
/usr/local/include/gnuradio/gr_hier_block2.h:64: note:
void gr_hier_block2::connect(gr_basic_block_sptr, int,
gr_basic_block_sptr, int)

What does the first one do?? It only takes a single block…

It is possible to connect a stand alone hierarchical block, with no
inputs or outputs, into a top block so that it gets added to the flow
graph. For example, you might have a transmit_path hierarchical
block, which does all it needs to do internally, and a receive_path
hierarchical block, which also has no inputs or outputs. To get these
into top block, you would do:

tb->connect(transmit_path)
tb->connect(receive_path)

The second one is presumably with ports? I will try that next.

Yes.

Can we
add a connect method that takes two blocks and assumes the ports are both 0?

The Python ‘connect’ call does all sorts of wonderful Pythonic things
like runtime inspection of arguments, so we can “do the right thing”
on a set of arguments that includes port specifications, or just block
instances. In C++, we have to rely on function overloading to do the
same.

It’s not something I’ve put a lot of thought into yet, but your
suggestion of adding a version of connect that takes two blocks and
wires output 0 of the first to input 0 of the second is a good one.

Thoughts?

I’m glad you’re trying this out. It’s actually been in the trunk for
many months.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

On Fri, Feb 22, 2008 at 09:22:37AM -0800, Dan H. wrote:

Dan H. wrote:

Suppose I want to build a C++ application to drive GNU Radio, using
captured trace data – so I don’t need the USRP.

Another observation: It looks like right now there’s no
super-header-file like “gr.h” that does the same thing for C++ that
“import gr” does for Python. This would also be useful :).

It would also create a ton of unneeded coupling, causing the universe
to be recompiled when anything was touched.

In your example the include of gr_runtime_types is unneeded.
Just start by including gr_top_block.h.

Eric