# Passing USRP source block shared pointer through SWIG **URL:** \ **Category:** GNU Radio\ **Created:** [March 23, 2015, 6:15pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705 "2015-03-23T18:15:27Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [March 23, 2015, 6:15pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705/1 "2015-03-23T18:15:27Z")
Hi all, I’m looking into the possibility of passing the \ 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](http://www.swig.org/Doc2.0/Library.html#Library_std_shared_ptr) Thanks in advance, -Doug ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 23, 2015, 7:59pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705/2 "2015-03-23T19:59:44Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 24, 2015, 8:11pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705/3 "2015-03-24T20:11:59Z")
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** () > > > \ > > ‘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: [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Martin B. [removed\_email\_address@domain.invalid] Sent: Monday, March 23, 2015 12:58 PM To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) * * * Discuss-gnuradio mailing list [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)** ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 24, 2015, 8:52pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705/4 "2015-03-24T20:52:19Z")
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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [March 24, 2015, 9:25pm UTC](https://www.ruby-forum.com/t/passing-usrp-source-block-shared-pointer-through-swig/234705/5 "2015-03-24T21:25:08Z")
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. [removed\_email\_address@domain.invalid] Sent: Tuesday, March 24, 2015 1:50 PM To: Anderson, Douglas J.; [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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