Packet via USB

GNU Radio
1

Hi at all,
i’ve a question.
I send a packet data with a variable length to USRP via USB every 1
second.
At the receiver side, using usrp_fft.py, i notice that the most part of
packets
aren’t transmitted.
Someone could help me?

Thanks
Giuseppe PIlla

2

On Mon, Jan 07, 2008 at 11:55:24AM +0100, [email protected] wrote:

Hi at all,
i’ve a question.
I send a packet data with a variable length to USRP via USB every 1 second.
At the receiver side, using usrp_fft.py, i notice that the most part of packets
aren’t transmitted.
Someone could help me?

Thanks
Giuseppe PIlla

The packets need to end up padded to the equivalent of 512 bytes,
typically 128 complex samples, otherwise they are not flushed through
the usrp interface.

Eric

3

Hi,
I’ve observed that all URB allocated in the Tx side are correctly
proccesed.
For example:
Data -> 25 Byte (from a mpg file)
Total payload -> 80 Byte (Data + CRC + Padding + Header + …)

Total Byte to transfer with a BPSK modulator -> 80 * 8 (bit of a char) *
6
(sample per symbol) * 4 (Byte - IQ) -> 15360 Byte (multiple of 512
Byte).

All URB buffers used are multiple of 512.
In fusb_ephandle_linux::submit_urb (fusb_linux.cc) i have inserted
wait_for_completion () function from which I get these massages: URB
list empy
(All request).

I transmit such packets every 1 - 2 seconds (no stream data). But I
can’t see
them on the Rx side using usrp_fft.py to observe the signal on the air.
I can
see some signal only occasionally. Is this problem reconducted to the
Host PC
side (maybe the Linux USB driver)?

4

On Tue, Jan 08, 2008 at 04:10:46PM +0100, [email protected] wrote:

In fusb_ephandle_linux::submit_urb (fusb_linux.cc) i have inserted
wait_for_completion () function from which I get these massages: URB list empy
(All request).

I transmit such packets every 1 - 2 seconds (no stream data). But I can’t see
them on the Rx side using usrp_fft.py to observe the signal on the air. I can
see some signal only occasionally. Is this problem reconducted to the Host PC
side (maybe the Linux USB driver)?

The tx side seems OK.

usrp_fft doesn’t (normally) process all incoming data, since it can’t
keep up. From your description, it looks like you are trying to
detect a very small burst sent once every 1 or 2 seconds.

Try logging the rx samples to disk using usrp_rx_cfile.py and then
examine the file using octave.

Eric

5

Hi, thanks you for your reply.
Tx side it’s all ok.
The problem is on Rx side,
Using Oscilloscope with usrp_fft.py or saving samples
on disk i noticed all packet are transmitted. This is true using high
value of
interpolation/decimation factor (very low bit rate).
What do you think about this?
It’s like “sweep time” of a digital spectrum analyzer, where a very
short burst
isn’t recognized? Or the problem is on the read routine where all URB
buffer’s
point at the same output buffer, especially in presence of a “weight”
demodulation block ?

Thanks.
Giuseppe Pilla

6

On Wed, Jan 09, 2008 at 03:57:58PM +0100, [email protected] wrote:

Hi, thanks you for your reply.
Tx side it’s all ok.
The problem is on Rx side,
Using Oscilloscope with usrp_fft.py or saving samples
on disk i noticed all packet are transmitted. This is true using high value of
interpolation/decimation factor (very low bit rate).
What do you think about this?

It’s like “sweep time” of a digital spectrum analyzer, where a very short burst
isn’t recognized?

Yes.

Or the problem is on the read routine where all URB buffer’s
point at the same output buffer, especially in presence of a “weight”
demodulation block ?

No, we get all the packets/samples.

You may be looking for a “burst detector” block.

Eric