[Top][All Lists]

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

Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and f

From: Hsin-mu Tsai
Subject: Re: [Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters
Date: Wed, 25 Jul 2007 15:25:40 -0400

Thanks for the quick response. I really appreciate it.

uO means "USRP Overrun". That is, the USRP is sending data to the
computer faster than the computer can handle it. This probably means
that you are sending at too high a data rate -- the online decoder is
taking too much CPU. When you start logging with the file_source, then
this CPU (and memory, etc) overhead disappears and all samples are
logged. Then when the decoded samples are replayed, your receiver has
ample CPU time to work.

I don't think my problem is related to the CPU. Here are my reasons:

1. I tried overclock my CPU from 2.6 GHz to 3.2 GHz in order to see if
an increase of CPU performance can decrease the packet loss ratio.
However, no significant change was observed. And I'm using Intel Core
2 Extreme QX6700 at 2.6 GHz, which is one of the most powerful CPU we
can get currently.

2. I guess I wasn't very clear in my first e-mail. I tried two
different kinds of setting with file_sink and file_source:

a)  TX_blocks -> usrp_source -> usrp board 1 ---physical_channel--->
usrp board 2 -> usrp_sink -> file_sink
then decode the signal with
file_source -> RX_blocks

b) TX_blocks -> file_sink
then decode the signal with
file_source -> RX blocks

a) still has similar results while b) has 0 packet loss. a) doesn't
involve real-time decoding (the CPU should have ample time to work
with the data), but it still has a lot of packet losses.

3. I've tried power squelch filter too. The results for both using it
and not using it are similar.

Once you've eliminated the uO's, if there are still packet losses, note
that the default GNU radio receivers are not perfect or even necessarily
that great... there might just be some problems recovering from the
default channel distortions. Finally, you can also play with the gain on
each end to attempt to improve the SNR. Which modulation scheme are you
using with which boards at which frequency?

One of the weirdest thing is that even when I'm using only usrp_source
-> file_sink, I can still have a lot of uO when using certain
fusb_nblock and fusb_block_size setting (and I believe my machine is
fast enough. I even tried saving the data to a file on the ramdisk).
How does these settings affect the probability of USRP overrun? If I
want to avoid samples being dropped, what setting should I use?

I'm using Thomas Schmid's 802.15.4 blocks (OQPSK) (was posted on this
mail list a while ago). I'm using RFX2400 operating at 2.4 GHz.

Also, just to make sure, when you connect two USRPs directly make sure
to use sufficient attenuation (~40dB I think, check the archives for
emails from Matt Ettus for the actual number) with any of the RFX boards
to avoid damage to the receiver!

That's good to know! (I didn't know this.) Is there anyway to make
sure that my board is not damaged?

Thanks again for your time.


Hsin-Mu (Michael) Tsai
Ph.D. Student
Electrical and Computer Engineering Department
Carnegie Mellon University

reply via email to

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