[USRP-users] Last packet corrupted on USRP1

Jawad Seddar jawad.seddar at gmail.com
Sat Feb 23 13:41:27 EST 2013


Hello,

I just started working with GNURadio 3 weeks ago.
I am currently using 2 USRP1 devices :
 - The first one is equipped with a RFX900 daughter board and a RFX2400
 - The second one is equipped with a RFX900 and a XCV2450

I have installed the latest GNURadio version on two computers (using the
build_gnuradio script) and have started playing around with those devices.

One of my first tests was to use the narrowband benchmark scripts in order
to check that I could send and receive on both devices and on any daugther
board. I could send and receive correctly (ok = true, no pktno missing)
using a variety of frequencies but not using the gmsk modulation (It worked
great using bpsk, dbpsk, dqpsk...).

After that first step, I went on and tried the narrowband tunnel.py example
but noticed that I wasn't seeing any packets at the receiver side though I
configured both gr0 interfaces on both computers and could see packets
being transmitted at the transmitter side.

After entering the arp tables manually on each computer, I still couldn't
ping any of the machines but oddly enough I could user iperf and send udp
packets from one machine to another. These packets were correctly received
but the answer got lost on the way back.

This got me thinking, what if only large packets could be seen at the
receiver? So I tried pinging using large packets (1400 Bytes) still
entering the arp manually, still nothing at the receiver (sometimes a
ok=false). Then I tried pinging and flooding (-f) still using large packets
(1400 Bytes), I could see the packets arriving and passing the CRC check
(ok = true).

So I went back to the benchmark scripts and played a bit with the
parameters. I noticed that when using the discontinuous mode (it sends 5
packets then stops for 1 second and repeats) I was receiving the 4 first
packets correctly but the last one failed the CRC check (ok = false). I
tried different packet sizes and different burst sizes (number of packets
in a row) and different sleeping times between emissions, I always get the
same results : the last packet doesn't pass the CRC check (sometimes the
first one as well).

So I thought that maybe the last bits of the transmission were corrupted,
so I went to the crc.py file and added stuffing bytes after the CRC field
and removed them at the receiver side. I went up to 2048 bytes of stuffing
(starting at 1 byte first), but it didn't yield much success.

Then I decided to send a dummy packet after each payload packet. I tried
different sizes for the dummy packet and got some results. For instance,
adding a 16 Byte dummy after an 8 Byte long payload did work but the size
of the dummy packet seems to be dependent on the size of the payload...

I can't seem to figure out what is causing the problem in the first place.
I have been thinking about synchronisation issues (because sometimes the
first packet is lost as well as the last one), or maybe power issues (the
transmitter shuts down before the last bit is out) . The last cause should
have been fixed by the stuffing after the CRC...

I thank everybody who has reached this point, I am currently looking for
any insights you might have on this issue.

Thank you for your help.

Jawad Seddar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130223/4a6b5abb/attachment-0002.html>


More information about the USRP-users mailing list