I am trying to deploy my radio application (using GRC), and I am running
into a problem. I am sampling at 50MHz and trying to pare things down to
30MHz using a Low Pass Filter, defined as follows:
Decimation = 50
Gain = 1
Sample Rate = samp_rate (50M)
Cutoff Freq = 30000000 (30M)
Transition Width = 1000 (1k)
I get an error telling me cutoff frequency is greater than sample rate /
2
(30 > 50/2).
How can I get down to 30MHz? I do intend to look at smaller “chunks” of
data at a time, so I am perfectly okay with taking data at 50MHz and
cutting it down later, I just wanted to avoid gather unnecessary data.
Thanks!
On Tue, Nov 19, 2013 at 6:35 PM, Paul B. Huter [email protected]
wrote:
I get an error telling me cutoff frequency is greater than sample rate / 2
(30 > 50/2).
How can I get down to 30MHz? I do intend to look at smaller “chunks” of data
at a time, so I am perfectly okay with taking data at 50MHz and cutting it
down later, I just wanted to avoid gather unnecessary data.
Thanks!
Set the cutoff freq to 15M, not 30M.
Tom
I recall that that was what you had mentioned yesterday, but could you
explain why setting it to 15M will allow me to grab 30M?
On Tue, Nov 19, 2013 at 7:19 PM, Paul B. Huter [email protected]
wrote:
I recall that that was what you had mentioned yesterday, but could you
explain why setting it to 15M will allow me to grab 30M?
Sure.
We’re working at complex baseband. The signal you capture at 50 Msps
will be observable from -25 MHz to +25 MHz. Because it’s a complex
signal, we have both sides around 0 Hz; also, it means that for a 50
Msps sampling rate, we can “see” 50 MHz of bandwidth.
So to get the middle 30 MHz, you want to define a filter that extends
from -15 to +15 MHz. A low pass filter is a real-valued signal. We
define it from 0 to 15 MHz, but because it’s real, it’s symmetric
around 0 and thus extends from -15 to +15 MHz.
Also, be careful about using 1000 Hz as your transition band. That’s
still going to generate a gigantic filter. Using a 100 kHz transition
band with a 50 Msps sampling rate produces a filter 909 taps long,
which is very, very long.
Use gr_filter_design (launched from the command line) to design a
filter that’s suitable. You can probably get away with a transition
band of 1 MHz.
Tom
I really appreciate the detailed explanation. I tried running
gr_filter_design last night and it asked me to install SciPy, which I
did
not feel like doing at that time. I will try using 1MHz for my band,
which
may help get rid of the real-time running issue.
Again, I appreciate your help with this matter.
Thanks, Marcus. I’m okay with not doing real-time, as long as I don’t
lose
a ton of data. I’m only going to be running for about 30 seconds at a
time.
So to get the middle 30 MHz, you want to define a filter that extends
filter that’s suitable. You can probably get away with a transition
band of 1 MHz.
Tom
You can actually be fairly “sloppy” with the width of the transition
bands and still produce a pretty-good filter. For 50Msps sample
rate, I’d use a 5-10MHz transition bandwidth. Also, if you’re really
sampling at 50Msps, you’ll not be able to do much in real-time
before your computer falls-over.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
I really appreciate the detailed explanation. I tried running
gr_filter_design last night and it asked me to install SciPy, which I
did not feel like doing at that time. I will try using 1MHz for my
band, which may help get rid of the real-time running issue.
Again, I appreciate your help with this matter.
Let’s say you get a filter that’s, oh, I dunno, 100 taps long. That
filter has to process every sample, so, that’s 5e7 X 100 taps, or
roughly 5e9 FLOP/second. Just for that one filter. And your
flow-graph is likely doing other things and it’s having to get samples
all the way through your network or USB stacks into the application
layer as well, call that 100 instructions/sample. So, that’s
5e7 x 100 = 5e9 OPS/second just to get your samples into the
application. You’re going to burn-up the cycles on your CPU pretty
quickly at 50Msps, even for doing “trivial” things.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Tom, that was a very useful explanation. Thanks!
How do you determine the size of taps? How much of a difference does
setting the transition width from 1MHz to 10MHz make?
Generally, the wider the transition width, the fewer taps.
You can use the “firdes” functions, which is what the low-pass filter
blocks call in gnuradio, then take their output into a variable and
have another variable be len(filter).
How do you determine the size of taps? How much of a difference does
setting the transition width from 1MHz to 10MHz make?
Paul,
Attached an ber simple flow graph, perhaps this is a better way to get
you going25MHz of bandwidth where ever you center the band, which with
an LFRX and your application would make most sense to be somewhere in
the range 12.5MHz-17.5MHz all written to file (as single precision
complex float) and to GUI FFT. All the filtering in this case is down in
the digital down conversion in the USRP.
-Ian
On Tue, Nov 19, 2013 at 7:58 PM, Marcus D. Leech [email protected]
wrote:
How do you determine the size of taps? How much of a difference does setting
the transition width from 1MHz to 10MHz make?
Generally, the wider the transition width, the fewer taps.
You can use the “firdes” functions, which is what the low-pass filter blocks
call in gnuradio, then take their output into a variable and
have another variable be len(filter).
Right. And the firdes functions use the windowing technique to build
filters. The way these work, in fact, is that a 10x increase in the
transition width produces a 10x decrease in the number of taps.
So for a 50 Msps sampling rate with 1 MHz transition width, we get 137
taps. For 10 MHz, we have 13 taps (floor(137/10)).
This is true as long as we’re keeping the stop-band attenuation the
same. There are _2 versions of each filter that allow us to set that
attenuation value (in dB). The approximate relationship is:
ntaps ~= atten / (22 * tb/fs)
(tb: transition bandwidth; fs: sample rate)
(Also, I once knew the derivation this relationship but can’t remember
it now.)
Tom