Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[M. Ranganathan]

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

On Thu, Nov 14, 2013 at 11:07 AM, Marcus Leech <address@hidden> wrote:

Why does the MAC block need to "reach around" way down into the depths of the PHY layer?

 

on Nov 14, 2013, M. Ranganathan <address@hidden> wrote:

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.

 

On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller <address@hidden> wrote:

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.

On 14.11.2013 15:39, M. Ranganathan wrote:

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

 

On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller <address@hidden> wrote:

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

On 14.11.2013 01:26, M. Ranganathan wrote:

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

--
M. Ranganathan

_______________________________________________
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

--
M. Ranganathan

--
M. Ranganathan

---

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

--
M. Ranganathan