discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP tuning time


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] USRP tuning time
Date: Mon, 10 Aug 2015 14:59:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hi Mat,
> I decided to achieve frequency hopping not by changing the centre
> frequency of the USRP, but by multiplying my signal with a sine of a
> certain frequency offset and then transmit that signal over the USRP
> with a fixed USRP. 
That's cool, but it's exactly what the FPGA of the USRP would have done
for you if you just used DSP tuning; but without having to use the full
sampling rate that covers the whole analog band. I do agree, it's often
easier to implement things this way, because everything stays within
control of your software.

The errors you describe sound like your USRP is actually running at a
different rate than what you've set. And in fact, the 150MHz you set are
not a rate that is possible with any master clock rate. You'll need to
use an integer factor of your master clock rate, which by default is
200MHz (but can also be configured to be 120MHz or 184.3MHz). So
possible rates are 200MS/s / 1, 200MS/s / 2, 200MS/s / 3 and so on. The
console output of your script should actually tell you that the rate is
unsupported and a different rate was used.

I'd say that it might really be a good choice to let the FPGA do this;
it's nothing you must task your CPU with if your USRP can do it! In
fact, it would not be overly hard to add the DSP-only tuning via stream
tags to the USRP sink, but since this might solve your problem
sufficiently well, why don't you try adding stream tags? For example,
replace your sinus source with a vector source with a constant list as
value (e.g. [1.0] * 1000* 3000) and a tags parameter, like the following:

[ gr.tag_utils.python_to_tag( (n*1000, pmt.intern("tx_freq"),
pmt.from_double(2.5e9 + n*1000), pmt.intern("src")) )  for n in
xrange(3000) ]

that should instruct the USRP sink to tune every 1000 samples. That way,
you don't have to interpolate to the full physical DAC rate, but just
enough to allow your frequency mod to work (which probably is much much
less).

Best regards,
Marcus


On 10.08.2015 14:00, Mat Mat wrote:
> hey man,
>
> many many thanks for the detailed reply! Based on it, I decided to 
> achieve frequency hopping not by changing the centre frequency of the 
> USRP, but by multiplying my signal with a sine of a certain frequency 
> offset and then transmit that signal over the USRP with a fixed USRP. 
> Unfortunately, a new problem has arisen. you can see my flowgraph 
> attached
>
> I want my signal to be transmitted on 5.804GHz. to this end, the centre 
> frequency is set to 5.799GHz, and the signal that I wish to transmit is 
> multiplied with a sine wave of 5MHz. (I'm storing everything as a file 
> before transmitting, as things are otherwise too slow). The problem now 
> is that when I transmit the signal over the USRP, it is not transmitted 
> on 5804 MHz but on approx. 5802 MHz. Furthermore, this error appears to 
> become bigger with bigger frequency offsets: When I want the signal to 
> be transmitted with 20MHz offset to the centre frequency of the usrp 
> (thus using a sine wave of 20MHz), the difference between the intended 
> signal frequency and the true signal frequency is almost 10 MHz!
>
> Am I doing anything wrong here??
>
> kind regards and thanks so much,
> Mat
>
> Attachments:
> http://www.ruby-forum.com/attachment/10982/modulator.jpg
>
>




reply via email to

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