USRP2 transmit to USRP1 issue

GNU Radio
1

The question: Has anyone gotten benchmark_tx.py (or tunnel.py) to work
from
USRP2 to USRP1?

I have built a fairly in-depth CSMA/CA MAC on top of the simple carrier
sensing in ‘tunnel.py’ to test the performance in some protocol
variations.
My setup works great with the USRP1s which I designed on. The problem
is we
ordered a USRP2 in edition to the 3 USRP1’s we have and I’ve had no luck
getting it to work with the rest. I am using RFX2400 d’boards.

The problem is packets sent by USRP2 are either not received at all by
the
USRP1 or occasionally received but with bit errors. The USRP2 IS able
to
receive USRP1 packets using DBPSK at 100Kbps successfully. I have tried
different rates making sure both give the same actual bitrate using the
verbose option. I set tx-amplitude=0.05.

I am using the 3.2.2 release, but have also tried the
benchmark_tx/rx2.py
using ‘dbpsk2’ in the developers branch with no luck.

Thanks for any input,

Phil Walsh
Auburn University

2

On Fri, Mar 26, 2010 at 7:38 PM, Phillip W.
[email protected] wrote:

USRP1 or occasionally received but with bit errors. The USRP2 IS able to
Auburn University
Yes, I developed the v2 of the digital stuff by testing them out
communicating between a USRP1 and USRP2 (both ways). Try increasing
the amplitude. Is this over-the-air or through a cable connection? You
can start with a cable (and a low tx-amplitude, < 0.2) to get a feel
for the received power you are seeing. But in general, it should work,
especially with the new dbpsk2/dqpsk2 since they have arbitrary bit
rates and you don’t have to worry about matching them between the
devices.

Tom

3

I met similar problem about the USRP2 transmitting. When I record the
received signal I found the signal that USRP2 transmitted out is not
continuous. Some signal segements are lost. This problem is independent
with
the data rate.

And this problem appears in some DELL computers but doesn’t appear in
one
IBM computer. I guess the ethernet chipset may be the reason. But I
didn’t
check this until now.

You may,

  1. Record the signal then check what happens
  2. Try another computer

BR
Lin

2010/3/27 Phillip W. [email protected]