[USRP-users] Last packet corrupted on USRP1

Josh Blum josh at ettus.com
Sun Feb 24 21:13:09 EST 2013



On 02/23/2013 12:41 PM, Jawad Seddar wrote:
> 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

> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




More information about the USRP-users mailing list