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
The program test_usrp_standard_tx reports
xfered 1.34e+08 bytes in 4.19 seconds. 3.2e+07 bytes/sec. cpu time = 0
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