Hello:
I need some help on a timing issue.
I have a timer running on a separate thread which changes parameters in
my flow graph every 100ms or 200ms. When I change the frequency of my
Signal Source by using gr.sig_source_c.set_frequency(), the timer thread
is still able to fire every 100ms or 200ms and change the tone frequency
every cycle. However, when I try to also change the center frequency in
the timer thread with usrp2.sink_32fc.set_center_freq(), it cannot keep
up and often takes more than 100ms or 200ms.
How long do functions such as usrp2.sink_32fc.set_center_freq() take to
execute? Do I need to to gr.lock() and gr.unlock() my flowgraph before
changing these kind of parameters? How can I change parameters every
100ms?
I’m running GNU Radio 3.3.0 on Linux.
Thanks for your help.
Steve McMahon
Hello Martin B.:
I’m not sure what you mean. There is no set_center_freq() method in
gr_sig_source_c.
When you say the best way to implement frequency hopping is to “use a
larger bandwidth and do the tuning digitally”, you mean to do the tuning
in software in the Python flowgraph using Gnuradio blocks?
Thanks.
Steve McMahon
On Thu, Dec 16, 2010 at 05:32:23PM -0800, Steve M. wrote:
Hello:
I need some help on a timing issue.
I have a timer running on a separate thread which changes parameters in my flow
graph every 100ms or 200ms. When I change the frequency of my Signal Source by
using gr.sig_source_c.set_frequency(), the timer thread is still able to fire
every 100ms or 200ms and change the tone frequency every cycle. However, when I
try to also change the center frequency in the timer thread with
usrp2.sink_32fc.set_center_freq(), it cannot keep up and often takes more than
100ms or 200ms.
How long do functions such as usrp2.sink_32fc.set_center_freq() take to execute?
Do I need to to gr.lock() and gr.unlock() my flowgraph before changing these kind
of parameters? How can I change parameters every 100ms?
Not the most general answer you can get, but if you want to do precise
retuning (e.g. for frequency hopping) to my best knowledge the way to go
is to use a larger bandwidth and do the tuning digitally. You don’t have
to use lock() for retuning the usrp (just as you don’t have to do so for
calling set_center_freq() on the sig_source).
Cheers,
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin B.
Research Associate
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu
KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
On 12/17/2010 10:28 AM, Steve M. wrote:
Hello Martin B.:
I’m not sure what you mean. There is no set_center_freq() method in
gr_sig_source_c.
When you say the best way to implement frequency hopping is to “use a
larger bandwidth and do the tuning digitally”, you mean to do the
tuning in software in the Python flowgraph using Gnuradio blocks?
Typically with frequency hopping applications, the closer you tune to
the host the faster, but the more constrained is your bandwidth, and
therefore tuning capabilities:
-
Tune in software: fastest option but tuning is the most bandwidth
constrained (how much can you tune with (25Msps on USRP2)). This is as
easy as changing your filter taps or changing the freq on a sig source.
-
Tune in FPGA DSP: second fastest option. Latency is the RTT/2 +
cordic delay. However tuning is now constrained by the bandwidth of
100Msps w/ USRP2.
-
Tune in the RF daughterboard: the slowest option with the largest
tuning range.
Two notes:
*) In uhd you can tune the FPGA DSP without re-tuning the daughterboard
settings using the tune_request struct. I dont think the capability is
available in the older gnuradio+USRP2 driver.
*) You may be able to modify the tuner code of the WBX to respond
quicker by example: if you know you dont have to switch VCO selection,
the tuning code could be optimized for latency by only tuning part of
the RF chip.
-Josh