On Thu, Nov 14, 2013 at 12:14 PM, Sylvain Munaut <246...@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.
>
>
> > A suggested "improvement" to the gnuradio code base (let me know
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 a
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 g
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
with
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 wrote:
> Why doe
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 actua
Why does the MAC block need to "reach around" way down into the depths of the PHY layer?
on Nov 14, 2013, M. Ranganathan 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 po
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
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 o
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
poin
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
migh
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 hac
12 matches
Mail list logo
