discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Tunning USRP From Seperate C++ Block?


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Tunning USRP From Seperate C++ Block?
Date: Sat, 09 Jun 2012 19:54:11 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]