Flex2400 and benchmark_rx.py - receiving only fraction of packets

GNU Radio
1

Hi all,
I am working with Flex2400 boards and the USRP. I have a question
about the digital module (GMSK data transfer). I observe this: When
I send 660 packets , I receive less than 400 of them and less than
200 are correct.

I setup two PCs with ubuntu and with an USRP each. The antennas were
connected to the TX/RX ports on each USRP and separated around 3.2m.
Basic
tests such as oscope and fft work fine, with one side sending. Then with
benchmark, on one end I use:
./benchmark_tx.py -f 2.412G --tx-amplitude=20000 -v -r 500k
and the other
./benchmark_rx.py -f 2.412G --rx-gain=70 -v -r 500k

For different runs, errors happen and in a typical run I get something
like
ok = False pktno = 662 n_rcvd = 355 n_right = 164

I did the following (which did not help)

  1. varied rx gain and tx_amplitude over a range
  2. checked the frequency 2.412 (using oscope and iwlist) and also
    changed to
    other free frequencies
  3. repeated experiment at a different time and day
    The ratio of the pktno to n_rcvd and n_right remains almost the same for
    different runs.
    Further, if I send send traffic the other way, I get lesser number of
    packets (100) correct.

Has anyone seen something like this? Specifically, I am looking at why
the
RX would receive only a fraction of packets and why only a smaller
fraction
would pass crc?

Thanks for your help,
Sri.
P.S. I am attaching the output of the rx side.

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

sri ram wrote:

P.S. I am attaching the output of the rx side.

uOok = True pktno = 47 n_rcvd = 48 n_right = 48
ok = True pktno = 48 n_rcvd = 49 n_right = 49
ok = True pktno = 49 n_rcvd = 50 n_right = 50
ok = True pktno = 50 n_rcvd = 51 n_right = 51
uOok = True pktno = 51 n_rcvd = 52 n_right = 52
ok = False pktno = 52 n_rcvd = 53 n_right = 52
ok = False pktno = 54 n_rcvd = 54 n_right = 52
uOok = False pktno = 56 n_rcvd = 55 n_right = 52
ok = False pktno = 58 n_rcvd = 56 n_right = 52

The USRP Overruns (the 'uO’s indicated above) mean that your computer is
not fast enough to process this data. Is the processor too slow? Are you
running other applications in the background?

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHcA9ry9GYuuMoUJ4RAgAHAKDQ+eAYlPfur+vSr+OGdxrCZHbNSwCfWC/L
G7g4Eh02xuO44VpTl/KtFr4=
=CSgi
-----END PGP SIGNATURE-----

3

Hello Dan,
I see that the u0 occurs once every 3 entries which
could
explain the ratio between the packets that are received and sent.

I am using a Pentium4 1.8GHz CPU. ‘top’ tells me that the processor is
98%
free and memory is also 95% free.
Do you still think that this computer is slow or is there any other
problem
that could have happened (such as the USB)?
I use a USB PCI card and the usrp_benchmark_usb gives 16MBps without
u0s.

Thanks for your quick response,
Sriram.

4

Hello Dan,
Using a higher decimation rate (128) , that problem does
not
arise.

Thanks,
Sriram