discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Re: question about RFX2400


From: Nick Foster
Subject: Re: [Discuss-gnuradio] Re: question about RFX2400
Date: Wed, 23 Feb 2011 18:27:43 -0800

On Wed, 2011-02-23 at 19:08 -0700, Malihe Ahmadi wrote:
> Yeah, I mean ref clock. I actually connect a 10MHz sin wave with 15dBm 
> amplitude to two USRP2, one acting as TX and the other one acting as RX. 
> the reason I am using this ref clock is to avoid the frequency offset 
> between the TX and RX (I have been observing about 1MHz offset between 
> the two). But yet there is about 1MHz frequency offset between TX and RX 
> and that is the reason I thought their are not locked to the ref clock. 
> Why would I still observe about 1MHz frequency offset then?

Dumb question, but are you syncing the source USRP2 (using config_mimo)
as well? Incidentally, 1MHz of offset at 2.4GHz is >400ppm, which is a
lot more frequency offset than I'd expect from two USRP2s tuned to the
same frequency. Can you post your source and sink flowgraphs?

--n

> 
> On 2/23/2011 2:32 PM, Ed Criscuolo wrote:
> > On 2/23/11 4:07 PM, Malihe Ahmadi wrote:
> >> Hi,
> >>
> >> I have included this line in my python flowgraph:
> >> |||sink.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)
> >> where sink is: ||sink ||=| |usrp2.sink_32fc()|
> >> but I think USRP2 is not locked to the external reference clock since
> >> when I turn this ref clock generator off, there is no change in the
> >> spectrum of the output of USRP2. My understanding is that if USRP2 is
> >> locked to the ref clock, when I turn the clock off I should see no
> >> signal at the output of USRP2. can somebody please help me with this?
> >> How do I get the USRP2 to lock to the ref clock?
> >>
> >
> > I believe this is a reference clock, not an external clock.  If so,
> > the USRP would continue to run on its internal clock, which has been
> > synced to the reference clock.  When the ref clock is removed, the
> > internal clock would continue to operate, slowly drifting.
> >
> > @(^.^)@  Ed
> >
> 





reply via email to

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