I built usrp and gr-usrp on Mac OS X, with some help from Michael Dickens. I linked with libusb from darwinports and IOKit from OS X itself. I have not made any changes to the fusb files in usrp/host/lib -- this is unmodified GNU Radio straight from CVS (checked out Nov 28 2005).
I observed the performance of several GNU Radio programs on two hardware configurations: a dual 2.7 GHz PowerPC G5 with built-in USB 2.0, and a 1 GHz Powerbook G4 with the Belkin F5U222 USB 2.0 card (this Powerbook only has USB 1.1 built-in). On both I ran Mac OS X 10.4.3, with a USRP Rev 2 with Standard TX and Standard RX daughterboards. I was pleased to find that, with the present USB support, GNU Radio can transfer at up to 4 MB/sec between the Mac host and the USRP (this confirms Michael Dickens' experience). This means that the software in its present condition can transfer audio frequency signals between the Mac host and the USRP, which should be sufficient for much of our MRFM work. Running test_usrp_standard_tx -I 128 (interpolation factor 128) on the G5 (with build in USB 2.0) reports no underruns and 4e+06 bytes/sec. At this same -I 128, the G4 (with the Belkin card) reports 12 underruns around startup and 3.992+e06 bytes/sec; -I 256 and -I 512 results in 11 and 5 underruns, respectively. Running a version with the statements that print "tx_underrun" commented out reports the same results. The TX-A output viewed on an oscilloscope (a real one) is a clean sine wave. Running on both machines with interpolation less than 128 results in many underruns throughought the run, and the scope shows flatlines alternating with the sinewave. Running usrp_siggen.py -i128 on the G5 results in no uUuUuU... output and the scope shows a sine wave. -i64 and smaller produces a stream of uUuUuU... output (indicating underruns) and some flatlines interrupting the sine wave. On the G4 + Belkin card, -i256 is the smallest interpolation that doesn't produce underruns. Running usrp_oscope -g0 -f0 -d64 (decimation 64) on the G5 results in just a few uOuOuO indicating overruns at startup. When a sine wave from a signal generator is connected to RX-A, the usrp_oscope display shows an uninterrupted sine wave. At smaller decimation, uOuO... appear continually and the display shows some discontinuous jumps. On the G4 + Belkin card, -d128 is the smallest decimation that does not result in continual uOuOuO... At this decimation the sampling frequency is 500 KHz. The 50 KHz sine wave from the signal generator is displayed at 10 samples/cycle without much distortion and 20 KHz looks very smooth. Likewise, usrp_fft -d64 on the G5 results in just a few uOuO at startup, and so does -d128 on the G4 + Belkin card. I tried usrp_siggen and usrp_oscope (or usrp_fft) at the same time on the G4 + Belkin, with TX-A connected to RX-A. With usrp_oscope -d256 and usrp_siggen -i512 I get no uOuO from scope and no uUuUuU from siggen. That's a sampling frequency of 250 KHz, so the scope display looks satisfactory on frequencies below 20 KHz. Jon Jacky PS. At startup all programs always complain "usb_control_message failed ... pipe is stalled" even when there are no underruns or overruns. For example: % ./usrp_siggen.py -i128 TX d'board A: Basic Tx usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled TX d'board B: <none> Press Enter to quit: PPS. In my installation, benchmark_usb always aborts with a failed assertion before reporting results: % ./benchmark_usb.py Testing 2MB/sec... TX d'board A: Basic Tx usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled TX d'board B: <none> RX d'board A: Basic Rx usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled RX d'board B: <none> usrp1_sink_base.cc:123: failed assertion `obi % 512 == 0' Abort _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
