[USRP-users] Last packet corrupted on USRP1

Jawad Seddar jawad.seddar at gmail.com
Mon Feb 25 13:31:10 EST 2013

> 2013/2/23 Jawad Seddar <jawad.seddar at gmail.com>
>> 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
> Is this a half duplex or full duplex operation? I think the tunnel.py
> type app has an issue switching the device out of TX mode because it
> doesnt set EOB, which messes things up like the arp reply on a half
> duplex system.
> I dont know if this project has ever been tried on USRP1, but its a good
> replacement for those benchmark* tunnel* examples in gnuradio:
> https://github.com/jmalsbury/pre-cog/wiki
> -josh

Thank you for the reply.

The benchmark_xx examples work in half-duplex i.e they either create a
source (benchmark_rx) or a sink (benchmark_tx) so no switching is required.
I think the problem comes from a lower layer but I don't know which one.

It is as if the emitter doesn't send the last packet entirely and that the
end of that packet is added at the beginning of the next packet causing the
first and the last packet of a burst to be corrupted.
I have checked the make_packet function inside the packet_utils.py file and
it seems to be padding the packets to 512 Bytes correctly.

I've had a look at the pre-cog project and used one of the provided
examples (simple_trx) but it doesn't seem to be working any better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130225/a4494326/attachment-0002.html>

More information about the USRP-users mailing list