Forum: GNU Radio Accessing the uhd_usrp object

Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-14 01:28
(Received via mailing list)
Hello all!

I want to write a block that can directly access the uhd_usrp_source.
This
block is a mac block hence it is up on the food chain and far away from
uhd_usrp_source in terms of its processing function. What is a good way
of
passing it a handle to the usrp_source ?

I can think of some hacks (such as a static global pointer where the
uhd_usrp_source C++ object registers itself) but it seems ugly to me to
take that route. Is there a better way to access global objects from
within
a block implementation.

Thanks in advance for any help.

Regards,

Ranga
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-14 10:08
(Received via mailing list)
Hi Ranga,

that's what pointers are for, after all. Just do it! Thanks to the
make()-magic you basically always have a smart shared pointer instead of
an block object (unless you really try to break the system ;) ).

Just a quick note though: MAC is usually timing-relevant. Timed commands
might not work as you expect, so please be aware that calling
set_command_time on your source might break functionality since there is
no out-of-order execution.

Greetings,
Marcus
Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-14 15:41
(Received via mailing list)
Marcus,

Thanks for your reply. What will the shared pointer be called. I see
stuff
like this in the code:

GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)


Presumably, that generates a structure that is registered as a global
pointer. So in my mac, I want something like

extern ....

At the risk of asking for too much help, can you give me some guidance
or
point me to a fragment of code somewhere that does this sort of thing.

Thanks,

Ranga
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-14 15:54
(Received via mailing list)
In GR 3.7, the shared pointer is usually blockname::sptr;

I can't really point you to a very good example, but when you call
top_block.connect(src, sink) in C++, you're giving it spointers :)

As I said, whenever you make a block, you actually get a shared pointer
to that instance, and not the object itself.
Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-14 16:55
(Received via mailing list)
Marcus,

Looking around I don't see where the pointer to the block is made
globally
visible. I am inclined to add some code to the make method to register
the
shared pointer in a global variable when the method is called. Since my
application has only a single USRP block (source and sink), there's no
danger of overwriting something.

My problem is this:

I have python code that creates the blocks and strings them together
etc.
but I want to actually access the created block from c++ code (in the
mac
block implementation).

Let me know if I am seriously astray.


Thanks again for your help.
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-11-14 17:13
(Received via mailing list)
Hi,

> Looking around I don't see where the pointer to the block is made globally
> visible.

No where.

There could be several UHD source/sink blocks, so nothing will be made
globally visible by GR.


> I have python code that creates the blocks and strings them together etc.
> but I want to actually access the created block from c++ code (in the mac
> block implementation).

You'll have to give the instanciated uhd source block as an argument
of your custom block constructor and play with SWIG to make the Python
object be converted back to a C++ smart pointer. Have fun.


> Let me know if I am seriously astray.

You are. Whatever you need to do, there has to be a better way.


Cheers,

    Sylvain
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-14 17:45
(Received via mailing list)
Hi Ranga,

either you're seriously astray or I don't understand what you want.
This is C++ running on an operating system with segmentation. There are
*no* globally visibly objects, there is only calls to the operating
systems / IPC to communicate with other processes and objects that live
within your own process that you can directly address. Ok, there's
shared memory, but you can't move a uhd_source to shared pages; that
doesn't make sense.

When you're in the same process, it's easy just to pass pointers around.
They are objects as everything else. Let's assume you construct a
flowgraph like
top_block->connect(uhd_source, processing, mac, sink)
then you can just do
mac->set_uhd_src_pointer(uhd_source)

which would be something like
mymac::set_uhd_src_pointer(uhd_source::sptr src)
{
_uhd_src_sptr = src;
}

which enables you to just
_uhd_src_sptr->set_center_frequency(20000);
inside your class.

Greetings,

Marcus
Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-14 17:56
(Received via mailing list)
Marcus,

Based on what you and others have replied, I think my "most elegant"
plan
of attack would be to toss the generated puthon glue code (which I
generated using grc-companion BTW) and do everything in C++ so I dont
have
to worry about the language interface at all.

This way, I will not need global shared pointers.

Thank you again for all the time you have spent responding to me.

Ranga
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2013-11-15 10:10
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-15 10:16
(Received via mailing list)
I am working on a dynamic spectrum mac where the MAC will reach out to a
TV
White space DB (and also potentially do spectrum sensing) and adjust the
centre frequency of the USRP periodically.

Thanks for your help!

Regards,

Ranga
0817fa933c74eec9b3fcf3a04e16f418?d=identicon&s=25 Sylvain Munaut (Guest)
on 2013-11-15 11:18
(Received via mailing list)
Hi,


First: Please pay attention and reply to the list and not to me
personally.


> A suggested "improvement" to the gnuradio code base (let me know what you
> think) :
> Please keep such objects in a globally visible list (I can provide a diff if
there is interest) so that applications such as mine can access them. UHD >
sources and sinks are likely to be quite static as are indeed most gr blocks I
would suspect.

What I think is that I wouldn't call that an improvement at all. IMHO
It's a horrible design ...


>> You'll have to give the instanciated uhd source block as an argument
>> of your custom block constructor and play with SWIG to make the Python
>> object be converted back to a C++ smart pointer. Have fun.
>
> It sounds quite messy and hence I had to ask this list if there was a better
> way.

Wait what ?  Passing the pointer cleanly between blocks is "messy",
but polluting the global application namespace is "clean" ??? I think
we have radically different idea of what's good design and what's not
...


> I am open to any ideas.  I could of course modify the gnuradio source code
> to export a global pointer but I'd love it if  I could leave the core source
> code alone.

If I'm not mistaken, you can control the UHD source / sink with
message passing to change the frequency. Then your MAC just has a msg
output port connecting to the uhd message input port to control it.

Cheers,

    Sylvain
Aed4de86bda84c7b1c5032905775f64d?d=identicon&s=25 M. Ranganathan (Guest)
on 2013-11-15 12:01
(Received via mailing list)
On Thu, Nov 14, 2013 at 12:14 PM, Sylvain Munaut <246tnt@gmail.com>
wrote:

> Hi,
>
>
> First: Please pay attention and reply to the list and not to me personally.
>


Mercy! That was an honest mistake. A thousand apologies.


> It's a horrible design ...
>


I agree. If you notice I started off with that premise (i.e. that it was
a
hack).



> Wait what ?  Passing the pointer cleanly between blocks is "messy",
>
> If I'm not mistaken, you can control the UHD source / sink with
> message passing to change the frequency. Then your MAC just has a msg
> output port connecting to the uhd message input port to control it.
>


I will look at the block again but I could not see that.


Thanks for taking the time to reply.

Regards,

Ranga
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.