Sorry for the time between replies. I've been taking exams and packing
up. Timing the frequency changes is not terribly critical, as long as
they stay in rough order with the incoming samples. Our current way
involves a separate script which generates RPC packets for the XML-RPC
server to change a variable for the frequency. This has actually worked
ok in testing but I'm concerned that the timing between GNURadio and the
separate python script could drift during extended tests, causing the
incoming samples to be correlated with the wrong frequencies. Doing
everything in C++ would still not give a true time base, but at least if
I called the frequency changes from the work function it would correlate
directly to the samples. Will take note of the set_command_time function
as it could definitely prove useful for this project.
Great job on the Gr-extras Josh! The PMT passing definitely seems much
more straightforward than feval. Even still, I'm leaning a bit towards
C++ for this project. That should allow me to simply pass a pointer of
the UHD Sink block to the block which is going to change it's frequency.
This same method would probably prove useful for other aspects of this
project as well. It would make it really easy to pass data between
blocks. I also have a lot more experience with C++ than I do with
Python. Problem is, I can't seem to find any documentation or examples
on constructing a flowgraph in C++. I'm not even sure which libraries
would need to be included. Is there somewhere that I can look for C++
examples/tutorials?
Thanks!
On 6/6/2012 2:10 PM, Josh Blum wrote:
So, no matter how you solve this, there different timebase thing is an
issue. On the N210/N200, there is a set_command_time. You will want to
use this to coordinate when tunes occur in relation to the samples.
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5
1) Now, something that I would like to do is create a message sink block
that turns an arbitrary PMT message into a function name + args and
calls this function in python on a block's methods; obviously this is
all from the context of a python flow graph. On your end, in c++ you
would add a message port to your block that posts these control message
to its message source output.
So thats possible given the project here (see message section):
https://github.com/guruofquality/grextras/wiki
You should be able to implement something on the c++ and python end with
the messages. But, I hope to make something like this more
strait-forward with the arbitration block described above.
2) If thats not feasible, there are these gr_msg_queue objects
(unrelated to the link above) that let you pass binary blobs around. You
can push into the queue in c++, and pop the message in a python thread,
call the setting...
I'd say either option is easier than implementing a wrapper of some sort
or using feval. Bringing it into c++ may not be too bad though...
-josh
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
