discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] One question regarding "-B FUSB_BLOCK_SIZE" and


From: Bishal Thapa
Subject: Re: [Discuss-gnuradio] One question regarding "-B FUSB_BLOCK_SIZE" and "-N FUSB_NBLOCKS"
Date: Mon, 28 Sep 2009 13:50:06 -0400

Dear Tim,
 First of all, thanks for your time answering my question. Secondly, one point you left out is: I am sending 104*128 bytes in reality, because I am spreading a packet of size 128 bytes with a 104 bits long spreading sequence right inside the pkt.py file in the
gnuradio-core/src/python/gnuradio/blk2imp/pkt.py location. Does not that mean I am not running into the USB block-size issue?

Lastly, question to the list and for Tim also, what does -N and -B options in ./benchmark_tx.py script represent? It says it is the block size for fast usb option and number of fast usb blocks in the description, what does this mean? Please help me understand. Thank you.

Sincerely,

On Sun, Sep 27, 2009 at 8:33 PM, Timothy Newman <address@hidden> wrote:
The minimum usb block transfer size (FUSB_BLOCK_SIZE) is 512 bytes, so while you may for example send 128 byte packets, the usb driver doesn't push it over the bus until it gets 512 bytes or 4 -128 byte packets.  Theoretically if you're packet sizes are a multiple of the buffer size then, I don't think this would be a problem, although you gonna have a bursty packet reception.  However, if for some reason your packet sizes are not a multiple and smaller than the minimum block size, then you'll have a fraction of a packet in a block, and the following block (with the other fraction) may not get sent if the buffer doesnt fill all the way up.   So you're not actually sending a full packet in that case, and it will look like packet loss.

Tim


Bishal Thapa wrote:
Dear Eric, Jonathan, List
  I am stuck in a simple problem, and I am wondering if I understand what  "-B FUSB_BLOCK_SIZE" and "-N FUSB_NBLOCKS" options do, then it MIGHT help a little bit.
  I am using benchmark_tx.py to send a payload of size 102 bytes, but with added header, CRC, padded "0x55"s it becomes exactly a 128 bytes packet. I spread this message using DSSS of length 104 in pkt.py and use interpolation rate of 256 and modulation dbpsk.
  On the receiver side, I collect complex baseband samples using usrp_rx_cfile capture with decimation rate of 128 into a file. When I observe the file using read_complex_binary and plot it in matlab, I only receive about 15 packets out of every 20 packets I send. Do you think, this is because of the USB transfers 512 bytes at a time, or simply the queues not being cleared out before the transmitter stops the transmit program. I do put a time.sleep(1) between every packet to make sure they are sent, which I actually do not like to do. Nevertheless, after all this, still i do not see all my packets/samples captured. Could you shed a little light on this please, if you don't mind. I was thinking may be setting -N to 1 and -B to 128 will help. But I promise I couldn't figure out what exactly these options will do for me. Thank you.

Sincerely,


1.Transmitter command:
sudo   ./benchmark_tx.py -f 2.4G -i 256 -m dbpsk --from-file=102bytesofA.txt -c 20 [-N 1] [-B 128]
 (-c: Added an option to represent the number of times benchmark_tx will send the same packet)

2.Receiver command:
usrp_rx_cfile.py -f 2.4G -d 128 foo.dat

3.Analysis In matlab:
I observer plot(abs(read_complex_binary('foo.dat'))). Five packets are missing on average. It is not consistent, sometimes its 10 sometimes its 3.

The minimum usb block transfer size (FUSB_BLOCK_SIZE) is 512 bytes, so while you may for example send 128 byte packets, the usb driver doesn't push it over the bus until it gets 512 bytes or 4 -128 byte packets.  Theoretically if you're packet sizes are a multiple of the buffer size then, I don't think this would be a problem, although you gonna have a bursty packet reception.  However, if for some reason your packet sizes are not a multiple and smaller than the minimum block size, then you'll have a fraction of a packet in a block, and the following block (with the other fraction) may not get sent if the buffer doesnt fill all the way up because you may be done sending packets, so you're left with a partially full usb block buffer that isnt sent.   You're not actually sending a full packet in that case, and it will look like packet loss.

This is just a limitation of USB, I've seen others who've lowered the minimum block size through various hacks, but the overhead when doing this offsets the gains typically.

Tim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]