Question about benchmark_tx and benchmark_rx

Hi,

Thanks for reading my mail. I would like to ask is there any additional
setup or configuration required to execute benchmark_tx.py and
benchmark_rx.py?

My problem is I tried to initiate simple communication between two USRP1
using benchmark_rx.py and benchmark_tx.py . I had browse through the
mailing list looking on how to use the file appropriately. Running
benchmark_tx.py also execute help which I follow closely but failed to
receive any packets. If I tried to execute at transmitter:

benchmark_tx.py -f 400M -S 10

and at receiver

benchmark_rx.py -f 400M -S 10

I did not received packet status. I only received ‘0’ in the terminal.
Is
it correspond to error?

I also read mailing list sent by other members but none mentioned about
not
able to execute benchmark_tx.py . If I missed any post, could anyone
please
provide me the link.

For additional information:
Gnuradio version used: v3.5.0rc0
USRP1 : revision 4
Ubuntu: 11.10
Daugtherboard: SBX

Please let me know if I had to provide any additional information.

On 12/01/2011 09:36 PM, Muhammad R. wrote:

receive any packets. If I tried to execute at transmitter:
I also read mailing list sent by other members but none mentioned


Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury

You’re asking for 10 samples per symbol, which may exceed the rate at
which your receiver computer can keep up, depending on
the modulation used, and the complexity of the modulation
techniques. Are you using the narrowband or ofdm examples?

The ‘O’ means overrun. The hardware (USRP1) is sending samples faster
than your computer can keep up.

Hi,

Thanks for your reply. I am using the narrowband example.

If I attempt using

./benchmark_tx.py -f 400M -r 250k -S 4

and

./benchmark_rx.py -f 400M -r 250k -S 4

which I worked out from reading the README file, the receiver still
output
overrun (many ‘0’). I verified that the transmitter working since my
spectrum analyser can pickup the signal from the transmitter.


Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury

Do the benchmarks work if you lower the bit rate? I.e., -r 62.5K. If
they work at lower bit rate, then you probably just need a faster
computer.

If not, have you tried calibrating the frequencies of your USRPs? Try
using usrp_fft (or uhd_fft) on your Rx, and see if your Tx shows up at
400M. An error of as small as 100KHz can render the packets
unreceivable (from personal knowledge).

Oh, and I verified that GNURadio 3.2 benchmarks work on my system:

./benchmark_tx.py -f 925M -T A -r 250K -S 4
./benchmark_rx.py -f 925M -R B -r 250K -S 4
USRP1 + (A)FLEX900 + (B)DBSRX

Hi,

I am using:
OS: Ubuntu 11.10 (which I read in blog said that it has some problem
with
gnuradio)
Gnuradio: 3.5.0 rc 0 (which I git from master branch)

I quite puzzled it’s not working with my current setup. It seems doable
by
many people but not me.

Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury

On Thu, Dec 1, 2011 at 10:15 PM, Muhammad R.
[email protected]wrote:

./benchmark_rx.py -f 400M -r 250k -S 4
Bachelor of Electrical and Electronic
University of Canterbury

What is your OS, version of GNU Radio, hardware?

By default, the digital benchmarks run GMSK, so that with 250 kbps rate
should be easily doable without overruns on most modern machines.

Tom

./benchmark_tx.py -f 400M -r 250k -S 4

Regards,
Muhammad

A common reason for this type of problem is frequency-offset between RX
and TX. On the RX side, use uhd_fft.py to observe the spectrum
and see where the receiver thinks the peak of the spectrum is. Then
adjust your ‘-f’ accordingly on a subsequent run of benchmark_rx.py.

Crystal oscillators aren’t perfect. Even an error of a few 10s of PPM
can add up to several Khz at center frequencies in the hundreds of
MHz. Unless the receive flow-graph has a way of correcting gross
frequency error, you will have to do that manually.

This is such a common problem that I’m surprised you haven’t covered it
in your coursework yet. Real radios (and radio channels) have
impairments that often aren’t adequately modelled by simulations.


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Wed, Dec 14, 2011 at 7:24 PM, Marcus D. Leech [email protected]
wrote:

./benchmark_tx.py -f 400M -r 250k -S 4

MHz. Unless the receive flow-graph has a way of correcting gross
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Can someone put this in the FAQ page on gnuradio.org? It probably
deserves
a more detailed explanation than a FAQ-level answer, but it’d be a
start.

Tom

Hi there,

I made some decent progress but refining the parameters for the
benchmark_tx.py and benchmark_rx.py without no errors. However, I can
only
transmit but I could not receive anything at the receiver side. Could
somebody suggest what might be the problem? I tried to work it but still
could not find answer on why I did not received anything.

Used code:

./benchmark_tx.py -f 400M -r 250k -S 4

and

./benchmark_rx.py -f 400M -r 250k -S 4

OS: Ubuntu 11.10 (which I read in blog said that it has some problem
with
gnuradio)
Gnuradio: 3.5.0 rc 0 (which I git from master branch)
Hardware: USRP1(transmitter), USRP N210(receiver)
Machine: Lenovo T510 (transmitter), Dell Desktop

Regards,
Muhammad

On 14/12/11 09:41 PM, Tom R. wrote:

Can someone put this in the FAQ page on gnuradio.org
http://gnuradio.org? It probably deserves a more detailed
explanation than a FAQ-level answer, but it’d be a start.

Tom

The fabled “someone” must have anticipated you:

http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#I-have-two-USRPs-and-when-I-transmit-on-one-and-receive-on-the-other-at-the-same-frequency-I-get-an-offset