A few questions

GNU Radio
1

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)

  1. 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.
2

On 06/03/2011 04:02 PM, Brenden S. wrote:

USRP2 Source ==> Throttle to 250k ==> Low Pass Filter (Decimation of 5
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.