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