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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
