[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] passing USRP source block shared pointer through
Anderson, Douglas J.
Re: [Discuss-gnuradio] passing USRP source block shared pointer through SWIG
Tue, 24 Mar 2015 19:10:38 +0000
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
<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
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
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.cons(pmt.intern("freq"), pmt.from_double(900e6)),
... pmt.cons(pmt.intern("lo_offset"), pmt.from_double(5e6))
From: address@hidden address@hidden on behalf of Martin Braun address@hidden
Sent: Monday, March 23, 2015 12:58 PM
Subject: Re: [Discuss-gnuradio] passing USRP source block shared pointer
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.
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:
> 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?
> Thanks in advance,
> Discuss-gnuradio mailing list
Discuss-gnuradio mailing list