discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] questions about USRP2 sink block and upconversion


From: Dan Harasty
Subject: Re: [Discuss-gnuradio] questions about USRP2 sink block and upconversion
Date: Wed, 03 Nov 2010 17:27:03 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

Marcus wrote:
It's usual in telecom systems for there to be some kind of AFC on the
receive side to compensate for transmit-side frequency error.
Can't this problem also be solved with a transmit-side correction?

If the "error" in this particular USPR2 LO is about 900MHz - 899.99701MHz = 0.00299 MHz, then won't telling the USPR2 to modulate to 900.00299 MHz pretty much get the tones to the right place?

I imagine the correction will change with device temperature and age, and also by intended "center frequency".

But as a first cut, won't that work?

-- Dan Harasty



On 11/3/2010 4:59 PM, Marcus D. Leech wrote:
On 11/03/2010 04:00 PM, Steve Mcmahon wrote:
Hello:

I am still somewhat new to GNU Radio. I am running GNU Radio 3.3.0 under 
openSUSE 11.2, and I have two USRP2 boards, each with a WBX daughterboard. I 
need some help understanding some fundamental things about GNU Radio and the 
USRP2 and upconversion.

I am trying generate a tone at 900.001 MHz (900,001,000 Hz). I am using GRC to construct a simple 
flow graph where I have a signal source block generating a 1 khz cosine at a sample rate of 195.312 
khz (=100e6/512), connected to a USRP2 sink block with the "decimation" parameter set to 
512, and with the "frequency" parameter set to 900M. I then look at the output on a 
spectrum analyzer. My understanding was that I should see a clear spike at 900.001 MHz, but I 
don't. Instead I see a peak at 899.99701 MHz. What am I doing wrong? I'm using the internal USRP2 
clock. Is this happening because the internal clock is good to only 7ppm?

There are two sources of error--one, as you've observed is the precision
of the reference clock on the USRP2.  And the other is whatever residual 
measurement error your
Spectrum Analyser has.  Synthesized LOs are only as good as the reference 
clock, at least from
a frequency-precision perspective.  If you want to do better than that, then 
you can use an
external 10MHz reference clock, such as a GPS frequency standard.

This is entirely normal for synthesized RF gear.  Measure just about any
commercial radio out there with a precision measurement device, and there'll be 
some residual
frequency error, unless you get lucky.

It's usual in telecom systems for there to be some kind of AFC on the
receive side to compensate for
   transmit-side frequency error.
In general, how do I need to setup the frequency of a USRP2 source if I want to place tones in the 
spectrum? I thought it was simple upconversion. If I want to modulate a multitone signal (say with 
sine components 1 KHz, 3 khz, and 7 khz) to obtain an upconverted signal with tones at 901 MHz, 903 
MHz, and 907 MHz, then I simply set the "frequency" parameter of the USRP2 sink to 900 
MHz, right? How exactly does the USRP2 do the upconversion? What exactly does the 
"frequency" parameter do?


The USRP2 takes your quadrature-sampled baseband signal, and
interpolates it up to the required Tx-side sampling rate.  It programs the Tx 
LO on the daughtercard to
the desired frequency, and sends it on to the Tx mixer.  Sometimes, due to LO 
frequency step
size limitations on specific daughtercards, the USRP2 FPGA will use a DUC 
(Digital Up-converter)
stage to get to exactly the desired frequency.

I'm not sure whether you meant 901,903 and 907Mhz, or 900.001MHz, 900.003Mhz, 
and 900.007Mhz.

For purposes of experiment, you can have 3 different signal generators,
add their outputs, and send the resulting multi-tone baseband stream on to the 
USRP2.


Attachment: dharasty.vcf
Description: Vcard


reply via email to

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