Packet chopping


#1

List,

We are implementing a packet-based system with gnuradio, and we
experience that the packets are not sent in one flush from the USRP.

In our transmitter we are maintaining a data path and a control path, so
we exactly know where is the beginning of a packet and where is the end.
We use this method to pad the outgoing complex waveform to the multiple
of 128 samples, as it is required by the USRP (in a particular setup our
packet is 468 samples long, so it is padded to 512 samples).

Image [1] shows the abs of the complex waveform that our transmitter
block produces, this is fed into the USRP sink (a copy of the ofdm
benchmark’s USRP sink). Image [2] shows abs from the received signal
when the transmitter was operating. You can discover the preamble in the
received signal and similar things to the rest of the packet, but this
is not continuous. Interestingly there seems to be some parts from the
previous packet before the preamble.

We tried to set the fusb_block_size of the USRP sink to 8, so this
buffer will hold a whole packet, but this did not help either.

Any ideas would be greatly appreciated.

Best, Peter.

[1] http://nd.edu/~pvizi/transmitted.png
[2] http://nd.edu/~pvizi/onair.png


#2

On Tue, Mar 10, 2009 at 4:13 PM, Peter V. removed_email_address@domain.invalid wrote:

Any ideas would be greatly appreciated.

Best, Peter.

[1] http://nd.edu/~pvizi/transmitted.png
[2] http://nd.edu/~pvizi/onair.png

Please label your axes! I’m not sure what I’m looking at here. Also,
from what I gather, you are doing a comparison, but you are using two
different ranges in the x-axis. I am not at all clear what the problem
you are having is from your explanation.

Tom


#3

Tom,

I’m sorry if I was not clear enough.

On Tue, 2009-03-10 at 17:03 -0400, Tom R. wrote:

Please label your axes! I’m not sure what I’m looking at here. Also,
from what I gather, you are doing a comparison, but you are using two
different ranges in the x-axis. I am not at all clear what the problem
you are having is from your explanation.

In image [1] you see the absolute values of the baseband waveform that
my transmitter produces (I did not plot the real and complex part
separately). In this case it is 512 samples long after padding with
zeros for the USRP. In [2] you can see a part of the received baseband
waveform (again only plotting the abs, not real and imaginary part).

As you pointed out the range of x axis is different, and that is exactly
the problem: the samples in [2] with high snr are belonging to my
packet, and it is not 512 samples long, rather it is spread over 1000
samples, which in my opinion means that the USRP does not send the whole
packet at once but in small chunks.

Best, Peter.

[1] http://nd.edu/~pvizi/transmitted.png
[2] http://nd.edu/~pvizi/onair.png


#4

Nevermind ; my python control thread was hogging execution.


#5

I am experiencing the same problem using transmit_path to send packets.
When I send a packet it is not sent as one continuous transmission.
Observing it on a spectrum analyser, the packet is sent as (random)
bursts with short quiet periods in between. I want the packet to be sent
as one continuous transmission with no gaps. I have played around with
the USB settings to no effect. What is causing these gaps to occur?