USRP1 Rev 4.3 Benchmark_tx/rx transmit/receive issue

GNU Radio
1

I am absolutely stumped, any help with this would again be greatly
appreciated.

Last week I had a question trying to get USRP2 to work in my MAC
testbed. I
decided not to worry about that for the time being and borrowed 2 USRP1s
from another research group to finish a project. However, I am not
unable
to get benchmark_tx/rx.py or obviously tunnel.py to work with these
USRPs as
I have hundreds of times before with the other USRPs.

My first 2 USRP1 are Rev 4.5.
I have 4 RFX2400 Rev 30, tested all successfully on 4.5.
USRP1s in question are Rev 4.3.
GNU Radio 3.3.2

The Rev 4.3 transmits a waveform that appears on rev 4.5 FFT as a good
gmsk
(tried dbpsk also) signal. I set the TX amplitude to 5000 and RX gain
to
30, but have tried many many values. The rev 4.3 will not successfully
decode the rev 4.5 signal either.

Literally when I swap the USRPs out with the exact same set up, it works
with rev 4.5 boxes. I have tested the usrp 4.3s including FFT, siggen,
etc.
and everything else seems fine other than packet decode and correct
transmitting. I also tried RFX900’s between those two with no avail.

I’ve tried all the parameters I could think. Do I need to use a
specific
older GR revision? Special decimation, interpolation, samples/symbol,
etc?

As a side note: the simple reliable MAC I have implemented which
includes
RTS/CTS (w/ threshold), ACK, multi-hop, multiframe transmit is working
great
(so far). I look forward to publishing it for the community when I
finish
this project.

Regards,

Phil Walsh
Auburn University

2

Solved it:

Installed an old version, GnuRadio 3.1.1, I had on disk and the rev 4.3
USRP1s seem to work fine now on that.

Is this a known/common issue?

3

On Apr 2, 2010, at 9:08 PM, Phillip W. [email protected]
wrote:

I am absolutely stumped, any help with this would again be greatly
I have 4 RFX2400 Rev 30, tested all successfully on 4.5.
FFT, siggen, etc. and everything else seems fine other than packet
community when I finish this project.

Regards,

Phil Walsh
Auburn University

It’s likely that the new USRPs you’re using have frequencies that are
too far apart from each other. This is a particular problem with the
higher frequency boards. Using usrp_fft.py, try to see what the
frequency offset is and compensate for it to some degree.

The older version of GNU Radio you got working I think did the
acquisition slightly differently and was able to handle the larger
frequency offset.

The new v2 code for the digital modulations in the Git tree should
correct this, too.

Tom

4

The new v2 code for the digital modulations in the Git tree should correct
this, too.

Tom

Thanks Tom! That definitely sounds like it could be the problem. I
will
see if I can solve it with a frequency offset.

Also a correction to my solution, it wasn’t GR 3.1.1 I got to work with
it.
It was the svn revision 8586. Just in case someone looks into it
further.

Phil