When running digital/ofdm/tunnel.py on two machines with two USRPs, I’m
having trouble sending and receiving between the two at some
frequencies. I have verified
Using the ‘–freq=5.18e9 --spec=A:0’ flags for all of the commands
- benchmark_rx.py can receive from benchmark_tx.py
- benchmark_rx.py can receive from tunnel.py
- tunnel.py can not receive from benchmark_tx.py - Constant TIMEOUT
messages at tunnel.py
- ‘tunnel.py --freq=5.1795e9 --spec=A:0’ can receive from
‘benchmark_tx.py --freq=5.18e9 --spec=A:0’
This also occurs when running tunnel.py on both ends. If both set to
5.18e9 both report TIMEOUT when they should receive. With one set to
5.18e9 and the other at 5.1795e9, the latter can receive but appears to
send at 5.179e9 and no TIMEOUT reported on the first device.
Setting the --rx-freq= and --tx-freq= flags appears to have the
same effect as --freq= Also, I have tested this with many different
combinations of the --bandwidth flag,
–fft-length/–occupied-tones/–cp-length, and also --tx-amplitude.
I also experienced this problem at 5 GHz. The problem appears to go
away at 2.5 GHz (or is at least masked by the lower frequency) because I
can communicate between two tunnel.py instances configured with
–freq=2.5e9 (with ‘–tx-amplitude=0.05 --bandwidth=2M --tx-gain=10’)
I am running UHD_003.004.000-6-g793c8c00 built from a recent copy of the
build-gnuradio script, and I have flashed the N210s using the images for
the N210 rev. 2 from uhd_003.004.000-release_Ubuntu-11.04.i686.deb The
USRPs are approx. 20 inches apart, although I have also verified that
the problems occur at around 5 feet apart. I know the XCVR2450 doesn’t
support sending and receiving simultaneously, but I was thinking there
would be enough time between sending and receiving for this not to be an
I am new to GNURadio and relatively new to the signal processing field
in general, so I apologize for the long and potentially silly question.
If you’ve read this far into the message, though, I greatly appreciate
your time and hopefully your advice!