Passing USRP source block shared pointer through SWIG

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_MAGIC2 to expose it, or am I kidding myself?

http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr

Thanks in advance,
-Doug

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

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 :slight_smile:

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: [email protected]invalid
[[email protected]invalid] on behalf
of Martin B. [[email protected]]
Sent: Monday, March 23, 2015 12:58 PM
To: [email protected]
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:

created in Python is not a proxy for the sptr, and I can’t figure out
pointer back is the cleaner and more correct solution.


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On 24.03.2015 12:10, Anderson, Douglas J. wrote:

[…]
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.

Hey Doug, thanks for the feedback. This is exactly the kind of issues
I’m interesting in.

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?

As you say, not yet – but we’re still figuring this out, and sending
tune requests is indeed very useful.

This whole concept of sending PMT commands is something that we want to
get right. I could imagine something like this:

(‘command’, ‘arg1’, ‘arg2’, …)

Then, all tune request arguments would be just in there.

What we have right now for UHD is:

(‘command’, ‘arg1’ [, ‘channel #’])

…which is kind of similar.

Something else I’d like to have in the commands is a timestamp. This
would be invalid for tags, but for PMT messages it would be fine.

Maybe we want command dicts? So you can have the command name as a
field, and then all the arguments as key/value pairs… but I want to
not rush off and do my own thing there.
We already had issues when Tom & I came up with different formats for
PMTs between the QT Freq Sink the UHD Source.

Cheers,
M

Yeah the dict idea was kind of what I was going for with the pairs (in
pseudo code)

tuple(
“command”,
pair(“param1”, val1),
pair(“param2”, val2),

)

It feels intuitive because it maps pretty well to the function call
“command(param1=val1, param2=val2)”, and it works with the current state
of PMT.

The only downside is it’s kind of icky to parse, but I’m not sure if
having a dedicated dict type would ease that any.

-Doug


From: Martin B. [[email protected]]
Sent: Tuesday, March 24, 2015 1:50 PM
To: Anderson, Douglas J.; [email protected]
Subject: Re: [Discuss-gnuradio] passing USRP source block shared pointer
through SWIG

On 24.03.2015 12:10, Anderson, Douglas J. wrote:

[…]
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.

Hey Doug, thanks for the feedback. This is exactly the kind of issues
I’m interesting in.

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?

As you say, not yet – but we’re still figuring this out, and sending
tune requests is indeed very useful.

This whole concept of sending PMT commands is something that we want to
get right. I could imagine something like this:

(‘command’, ‘arg1’, ‘arg2’, …)

Then, all tune request arguments would be just in there.

What we have right now for UHD is:

(‘command’, ‘arg1’ [, ‘channel #’])

…which is kind of similar.

Something else I’d like to have in the commands is a timestamp. This
would be invalid for tags, but for PMT messages it would be fine.

Maybe we want command dicts? So you can have the command name as a
field, and then all the arguments as key/value pairs… but I want to
not rush off and do my own thing there.
We already had issues when Tom & I came up with different formats for
PMTs between the QT Freq Sink the UHD Source.

Cheers,
M

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs