|
From: | Marcus D. Leech |
Subject: | Re: [Discuss-gnuradio] A few questions |
Date: | Fri, 03 Jun 2011 20:17:01 -0400 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 |
On 06/03/2011 04:02 PM, Brenden Smith wrote:
Hello everyone, I am new to GNU Radio and the USRP2, but I have been playing around and have successfully made a FM receiver. I have a few questions:Any GigaBit card supported by Linux is supported by UHD/GnuRadio. Some are better than others--the cheaper ones tend to have poorer buffering and lousier interrupt-aggregation support, but at low bandwidths, it shouldn't be a problem. But I'm afraid that you're badly confused about the CPU cycles required compared to the clock-rate of the USRP2. Basically, the number of MIPS (Millions of Instructions Per Second) is proportional to: bandwidth(samples/sec) X inherent-complexity-of-processing So, for a signal that is 200Ksps (as the example I've attached), if you only needed to do one intrinsic CPU operation per sample, you'd need a 200KHz CPU. But, of course, you may end up executing hundreds to thousands of instructions for each sample, which is why the faster your CPU the better, although multiple-cores also helps in Gnu Radio, since it schedules blocks in parallel "threads", and this will often help. Furthermore, most CPUs these days, on average, complete more than one instruction per nominal clock cycle, so relating the CPU clock frequency to incoming sample rate is a very imprecise business indeed. I've attached my rendition of a simple AM receiver which has a couple of "diagnostic" FFTs, audio output using the "plughw" ALSA device, and an audio output "scope". Use it in good health. The AGC2 parameters I used worked well for a similar receiver I did last summer for listening to narrowband 27MHz CB signals. This flow-graph drives the audio subsystem at 20KHz, derived from the 200KHz incoming sample rate from the USRP2. Using the "plughw" device will arrange for ALSA to do re-sampling internally, and eliminate the requirement to do that in the flow-graph. Your flow-graph looks reasonably sane, but there's *NO* reason to put a throttle block in there at all--since the hardware at *both* ends of your flow-graph will inherently "throttle" the stream. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org |
bcband_am_receiver.grc
Description: application/gnuradio-grc
bcband_am_receiver.py
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |