Forum: GNU Radio Packet chopping

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
633bc96031fbd17086b6492f633cf649?d=identicon&s=25 Peter Vizi (Guest)
on 2009-03-10 21:13
(Received via mailing list)
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
A576b201df57014077494da786319110?d=identicon&s=25 Tom Rondeau (Guest)
on 2009-03-10 22:05
(Received via mailing list)
On Tue, Mar 10, 2009 at 4:13 PM, Peter Vizi <pvizi@nd.edu> 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
633bc96031fbd17086b6492f633cf649?d=identicon&s=25 Peter Vizi (Guest)
on 2009-03-11 16:52
(Received via mailing list)
Tom,

I'm sorry if I was not clear enough.

On Tue, 2009-03-10 at 17:03 -0400, Tom Rondeau 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
B76b7df24ed688b90162dc822eb5ab9c?d=identicon&s=25 William Sherman (tecumseh11)
on 2009-09-25 00:55
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?
B76b7df24ed688b90162dc822eb5ab9c?d=identicon&s=25 William Sherman (tecumseh11)
on 2009-09-25 01:22
Nevermind ; my python control thread was hogging execution.
This topic is locked and can not be replied to.