[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Basic questions

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Basic questions
Date: Mon, 12 Sep 2011 16:36:31 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2

On 12/09/2011 3:16 PM, Greg Le Sage wrote:
I have been searching for some basic documentation describing the GRC components without much luck. For instance, I can't find an explanation of why multiplying with a 50ksps sine wave specified to have zero frequency and an amplitude of 1 has any effect, though I have seen it in several examples e.g. an SSB transmitter. I am using the LFRX, which has no frequency conversion capability, but the "Frequency" setting in the USRP2 block certainly has an effect. What is it doing to the LFRX hardware? How can I decimate in the USRP2 block and separately specify a frequency? If I put a constant input to a USRP2 sink, it produces a tone at the frequency specified in the block. I am not sure what is actually happening in the LFTX daughterboard in that case since it seems to be a DC input. I want to read about the Throttle block, how it works, and when it is needed. I want to understand the differences between the frequency translating FIR filter and decimation. I looked at the Doxygen documents on gnuradio.org, but those are more about describing data structures and such details. The Ettus FAQs also don't cover these issues.
There is a general tutorial on GRC here:


It pre-dates UHD, but should give you a reasonable head-start

Unfortunately, there isn't a really good user manual for Gnu Radio, as such.  There are discrete documents sprinkled throughout the web,
 and there's also:


Some of the questions you're asking are more generic DSP questions, unrelated to Gnu Radio specifically, so you might also find some
  of the generic DSP books useful.

When you set the "frequency" of a source/sink block and that terminates in hardware that doesn't have an analog up/downconverter,
  the FPGA will attempt to digitally translate the baseband up to the desired frequency.  It can only translate up to the nyquist limit of
  the DAC, however.

I recommend that you use the UHD source/sink blocks if you have no need to be backwards compatible with the "classic" API.  They
  are more consistent, and are generally hardware agnostic.

What you present to a UHD source/sink is a baseband signal, at some sample rate.  You have to tell UHD what that rate is, so that it can
  calculate the required interpolation (for TX) or decimation (for RX) in the FPGA hardware.  Fractional rates aren't supported at the
  hardware interface, so the sample stream rate that gets presented had better be a proper divisor of the sample rate offered by the
  underlying hardware.  There are fractional resamplers of various kinds inside Gnu Radio that will help you adapt a stream that is at
  some "weird" (from the hardware's perspective) sample rate.

The throttle block is utterly unnecessary if the flow-graph either terminates or originates in any real hardware--such as audio or UHD.
  It is used only to rate-limit flow-graphs that are "pure simulations", it is an "artifact" of the way the flow-graph scheduler works,
  in effect, and can be safely ignored when real hardware is involved.

The frequency translating FIR filter is typically used to carve off some chunk of spectrum, and then shift it down/up to baseband. Optionally,
  you can decimate this new baseband signal at a rate that is appropriate to the bandwidth of the signal.  For example, you might have
  some chunk of input spectrum that is 4MHz wide, and you want to carve off 3 channels from that at random places with random
  bandwidths--you'd use three different frequency-xlating FIR filters to carve off the channels, and likely decimate them, and then
  "do stuff" with the resulting channels.  For equi-spaced channels, the PFB (Polyphase Filterbank) may be a more appropriate tool.
  There are performance implications, and sometimes it's not always obvious without detailed experiment which to chose.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]