Re: [Discuss-gnuradio] A few questions

[Marcus D. Leech]

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:

1) When I am receiving AM radio frequencies and demodulating them with the AM demod block I get no audio period, no static, nothing. The only thing I get is clicking when I try to up the volume to a point past what the sound card can play. Is there something silly I am missing that isn't allowing me to hear the AM radio: here is my block diagram:

USRP2 Source ==> Throttle to 250k ==> Low Pass Filter (Decimation of 5 and a variable cutoff and width) ==> Rational Resampler (Decimation: 500, Interpolation 441) ==> AGC2 (Attack Rate: 100m, Decay Rate: 10u, Reference: 900m, Gain & Max Gain: 1) ==> Am Demod (Channel Rate 44.1k, Audio pass: 5k, Audio stop: 5.5k) ==> Multiply Const (volume adjust) ==> Audio Sink (Sample rate: 44.1kHz)

2) I am intending to build a setup that includes a headless computer and the USRP2 packaged together, when looking at PCs what gigabit ethernet cards are supported (or is it any supported by the linux kernel), and if the clock speeds on the computer (in the buses, cpu, etc.) are as fast as or faster than the clock speed of the USRP2 I shouldn't run into any trouble processing the data, correct? I only ask to make sure before I order the computer.

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