[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb
[Discuss-gnuradio] High packet loss problem (samples dropped?) and fusb parameters
Wed, 25 Jul 2007 14:15:09 -0400
I'm running some packet transmission experiments using GNU Radio and
USRP. However, the packet loss ratio is very high (20%) even when I
directly connect two USRP boards, which are the transmitter and the
receiver, with a direct antenna cable (I've also tried using regular
antennas, but the packet loss ratio is about the same). I suspect that
the samples are dropped somewhere from usrp_sink -> usrp board ->
physical channel -> usrp board -> usrp_source, but I couldn't pinpoint
the source of the problem. I was hoping that someone on the mail list
might have an idea about what's causing the problem.
I'm positive that the signal processing blocks are working because if
I replace usrp_sink with file_sink on the transmitter and replace
usrp_source with file_source on the receiver, the packet loss ratio
immediately drops to zero.
I also tried using usrp_rx_cfile.py in gnuradio-examples to log the
signal in a file, then feed the file into the receiver side. It still
shows about 20% of packet losses. If I lower the data rate (hence the
sampling rate), the packet loss ratio gradually drops. But even when
I'm using the smallest data rate setting, it still shows some packet
One interesting thing I noticed is that when I increased fusb_nblock
and fusb_block_size, it shows a lot of buffer overrun ('uO'). When I'm
using the default setting, these uO disappear. Why is this happening?
However, the packet loss ratio are high in both cases. And I also
tried enabling real time scheduling, but it doesn't have much effects.
I'm using GNU Radio 3.0.3 release with Fedora Core 6. I've also tried
Debian 4.0r0, but the results are similar. I've already tried running
the same code on 3 different machines, all with similar results.
I felt that I have exhausted everything that can go wrong (which I can
think of). I would greatly appreciate any suggestions/comments from
the mail list. Many thanks.
Hsin-Mu (Michael) Tsai
Electrical and Computer Engineering Department
Carnegie Mellon University