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!
View this message in context:
http://old.nabble.com/My-USRP-sometime-can-receive-data%2C-sometime-not!-tp32385631p32385631.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Fri, Sep 2, 2011 at 6:37 AM, Lebowski80 [email protected]
wrote:
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