[Top][All Lists]

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

[Discuss-gnuradio] usrp_siggen.py underruns

From: Dominik Auras
Subject: [Discuss-gnuradio] usrp_siggen.py underruns
Date: Wed, 11 Feb 2009 19:35:10 +0100
User-agent: Thunderbird (X11/20090105)


I am currently observing an odd behavior of usrp_siggen.py.

When I start the program as follows

./usrp_siggen.py -f 2.40G -i 16 --gaussian

there are a lot of underruns (uU). However, for all other signal generation options except gaussian, it works fine (i.e. const, sine, uniform). Just to see, I have modified usrp_siggen to enable realtime scheduling. It didn't make the underruns go away.
My /etc/security/limits.conf contains the line
@usrp           -       rtprio          90
as suggested by a recent post to mailing list (though I increased the maximum priority). libgruel realtime functions sets the priority -30 (checked with top). CPU usage is ~ 103%.

I have observed a similar behavior with my transmitter system, if I set the bandwidth to 8 MHz, which should be the maximum. To me, it seems like the GnuRadio USRP driver can hardly keep up with this rate (it should be the maximum supported). Measurements without the USRP sink revealed that my transmitter actually sustains rates over 30 MS/s. Though I didn't test what rate the gaussian noise source in usrp_siggen achieves if connected to a nullsink. Further, with the USRP2, my transmitter sends continuously at a bandwidth of 12.5 MHz, no problem. However I need the USRP1 too.

My gnuradio version is from the svn trunk, but it's not the latest one. Some revision above 10000. If necessary, I could do a test with the latest revision.

The program test_usrp_standard_tx reports
xfered 1.34e+08 bytes in 4.19 seconds.  3.2e+07 bytes/sec.  cpu time = 0
0 underruns

My machine is a Core i7 940, 3 Gb RAM. I am using a fresh install of Ubuntu 8.10. The USRP owns his proper USB root hub, i.e. no other devices connected. Hence I think it is unlikely to be caused by the machine.

Best regards

reply via email to

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