On 06/06/2012 08:54 AM, labarowski wrote: > > Hello, > I would like to make a signal processing block which would generate a > certain number of samples (corresponding to a specific time window), pass > them to a USRP sink, then tune the USRP to a new frequency and repeat the > process. The issue that I'm running into is that I'm not sure that there is > a way for me to tune the USRP sink from a separate C++ block within a python > flowgraph. There is a method under gr_uhd_usrp_sink.h in the GNURadio 3.6 > API which looks like it would do the job, but I'm not sure that it is > accessible if I don't have direct access to the UHD sink at the C++ level, > which in this case I wouldn't as it is in another signal processing block. I > have also been reading about gr.feval, which should allow me to call the > python tune method from C++ (http://www.ruby-forum.com/topic/174437). I'm > having trouble seeing how feval works in gr_bin_statistics_f.cc and the > GNURadio 3.6 API though. Is there any other documentation or examples of > feval? > > From what I know so far, my options are to: > 1.) Make a separate block which uses the feval function to change the > frequency in Python. > 2.) Do all of the frequency changing in python. This is not desirable as my > understanding is that the python flowgraph will not share a timebase with > the samples passed between blocks. This might be acceptable though. The RPC > server with a separate python script acting as a client has worked thus far > but we have had to add extra delay time just in case and I would be a bit > worried about the possibility of the two time bases drifting with long term > use. > 3.) Construct a wrapper block for the UHD sink. The wrapper will be used in > the flowgraph and will itself call the actual UHD sink and (should) have > access to its tune method > 4.) Just make the whole flowgraph in C++ > > What are your thoughts on this? Is there some other option that I'm unaware > of which will make this easier? I'm somewhat inclined to make everything in > C++ at this point. This would keep all variables/methods accessible and may > make it easier to keep a common timebase, although I think each individual > block will still be running in a separate thread (please correct me on this > if I am wrong). I look forward to hearing the opinions of those more > experienced than me. I have found this mailing-list very useful in the past.
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
