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
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]
[[email protected]] on
behalf of Martin Braun [[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:
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 [email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ 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
