Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG

[Anderson, Douglas J.]

Hi Martin, sorry for the slow reply, I've been having "fun" with SWIG.

I was able to pass the usrp_source instance into my block after I discovered 
that SWIG adds a __deref__ method that exposed the naked pointer, then I just 
had my block take "gr::uhd::usrp_source*" type. 

>>> u = uhd.usrp_source(device_addr="", stream_args=uhd.stream_args('fc32'))
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
>>> u.__deref__()
<gnuradio.uhd.uhd_swig.usrp_source; proxy of <Swig Object of type 
'gr::uhd::usrp_source *' at 0x7f0e0f796660> >

I'm not sure if this is a better or worse way to do things than passing the 
basic block sptr and casting.

To answer you question about what I'm trying to do: I'm trying to create a freq 
sweeping flowgraph that's as efficient as possible. I have a setup like:

USRP -> controller -> fft -> stats -> etc...

... where controller tunes a center freq, waits for "rx_freq" stream tag, 
copies enough samples for the fft, retunes and then drops samples until the 
next "rx_freq" tag.

My problem with the usrp_source message interface is that currently you can't 
set a persistent LO offset (the code block has yet to be implemented). Even if 
it was implemented, I'm guessing you'd still have to send one "freq" command 
and one "lo_offset" command, and the freq command currently uses the overloaded 
set_center_freq function that spams the terminal with

-- Tune Request: 911.254883 MHz
--   The RF LO does not support the requested frequency:
--     Requested LO Frequency: 911.254883 MHz
--     RF LO Result: 911.257631 MHz
--   Attempted to use the DSP to reach the requested frequency:
--     Desired DSP Frequency: 0.002748 MHz
--     DSP Result: 0.002748 MHz
--   Successfully tuned to 911.254883 MHz

I haven't figured out how to turn that off when you instantiate the the 
usrp_source block in a python flow graph and THEN send retune messages from 
inside a c++ block... and those messages get very annoying in a sweeping 
flowgraph :)

I actually considered implementing the lo_offset message code myself and then 
doing a pull request, but I just couldn't think of a good way to match the 
flexibility of a tune_request struct within the confines of a single pmt 
message.

I wonder if there's a way for the message interface to accept a message 
formatted like this and then construct a tune_request from it?

>>> command = pmt.make_tuple(
...   pmt.intern("tune_request"),
...   pmt.cons(pmt.intern("freq"), pmt.from_double(900e6)),
...   pmt.cons(pmt.intern("lo_offset"), pmt.from_double(5e6))
...   )

-Doug

________________________________________
From: address@hidden address@hidden on behalf of Martin Braun address@hidden
Sent: Monday, March 23, 2015 12:58 PM
To: address@hidden
Subject: Re: [Discuss-gnuradio] passing USRP source block shared pointer 
through SWIG

You should easily be able to pass a basic_block sptr and then
dynamic-cast it in your block.

What you're trying to do is not recommended procedure, although I can
see how it's necessary at times. Can you tell us what you're trying to
do? We've been working on making the message ports more useful, which
should hopefully take care of most issues.

M

On 23.03.2015 10:13, Anderson, Douglas J. wrote:
> Hi all,
>
> I'm looking into the possibility of passing the <gr_block gr uhd usrp
> source (0)> object from Python into a C++ out of tree module. In my
> module, I have:
>
>      controller_cc_impl::controller_cc_impl(gr::uhd::usrp_source::sptr
> usrp, [...])
>
> I get a TypeError when I instantiate the block. It seems like the object
> created in Python is not a proxy for the sptr, and I can't figure out
> quite how to get access to the sptr from Python.
>
> I've tried both of the alternatives to passing back in the sptr: I've
> tried sending commands to the USRP via message passing interface, but
> only freq and gain are implemented. At the very least I need the full
> tune_request capability.
>
> I've also tried making that call with fevall_dd, but it's a blocking
> call and it's too slow for my application. I could maybe spawn that call
> in its own thread so it doesn't block, but I think passing the shared
> pointer back is the cleaner and more correct solution.
>
> So, how hard is this going to be? SWIG 2.0 supports boost's shared
> pointer. I'm wondering if it'd just be a few extra lines in
> GR_SWIG_BLOCK_MAGIC2to expose it, or am I kidding myself?
>
> http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr
>
> Thanks in advance,
> -Doug
>
>
> _______________________________________________
> 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