discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] My USRP sometime can receive data, sometime not!


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] My USRP sometime can receive data, sometime not!
Date: Fri, 2 Sep 2011 09:31:01 -0400

On Fri, Sep 2, 2011 at 6:37 AM, Lebowski80 <address@hidden> wrote:

Hello everyone,

I've got four USRPs and they are equal and the boards integrated are
XCVR2450 Transceivers. I want to transmit data from one USRP to another one
using the code found in benchmark_tx.py and benchmark_rx.py; I'm doing the
experiments using two USRPs at a time. Three of them work well; I mean that
they can transmit and receive correctly what I send. Changing their roles
(sometimes I use one USRP to transmit and sometimes to receive), they keep
working well. Only one of them sometimes can receive the packets while
sometimes it cannot receive anithing, I was doing always the same experiment
with the same code and the same hypothesis (i.e. fequency, bit rate...), I
suppose that such a USRP has got some factory defect but I'm not sure! Can
anyone tell me wich is the problem? As the hardwares and the software that
I'm using are the same how it is possible to get different results?

Thanks in advance!

It's quite possible that it's a frequency offset issue with the USRPs. There is a lock-in range for the digital modulation benchmark codes, and if you are outside of it, then you won't be able to acquire and synchronize the signal. It sounds like you might be just on the edge, which would explain the intermittent results. This is due to the nominal versus real frequency of the oscillators, so when you set the frequency to, say, 2.45 GHz, the real frequency is 2.45 + delta GHz where delta the frequency error in the oscillator multiplied by the scaling factor to get to 2.45 GHz.

You're best bet is to use the usrp_fft.py (or uhd_fft.py if you are using the UHD interface) to look at the signal you are receiving. If you can see a significant frequency offset from what you expect, you can correct for the coarse difference to get the signal to within the locking range of the receiver and let it take care of the rest.

Tom


reply via email to

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