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 <mle...@ripnet.com> 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* <mra...@gmail.com> 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 <mar...@hostalia.de> 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 <mar...@hostalia.de>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 >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> >> -- >> M. Ranganathan >> >> > > > -- > M. Ranganathan > > ------------------------------ > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -- M. Ranganathan
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
