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

[Hsin-mu Tsai]

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.

-Michael


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