On 06/09/2012 04:58 PM, Daniel Labarowski wrote: > 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. >
Well, whatever works is the right answer. :-) Even calling tune from the work function of your block is still going to have time ambiguity with the samples. You never know how much is buffered in the kernel or in a gr stream. I suppose an indirection of RPC would add some latency and possibly exacerbate the problem. I can't say by how much. Timed commands aside, the next safest thing you can do is shut off the streaming (start/stop methods of the source block) if you dont want any ambiguously tuned samples. > 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 BTW, I just produced a PMT RPC block, code here: https://github.com/guruofquality/grextras/blob/master/python/pmt_rpc.py You can stick this block in a python flow graph and it will parse its incoming messages and make calls on the flow graph. You can produce the messages for the RPC block in python or C++ work() function. I'm not pressuring you to use it or anything, but your inquiry did spark a neat idea :-) > 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? > Here is a blocks coding guide I wrote for GNU Radio: http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide And here is the equivalent document for GrExtras: https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide Looks like I left the top_block part of the guide as TODO, but here is a good example for that: http://gnuradio.org/cgit/gnuradio.git/tree/gr-audio/examples/c++/dial_tone.cc -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
