Hi Al,
you'll laugh, but under the hood, the rational resampler *is* a
filter! And the way you configured it, it has very many taps. So,
the correct solution is actually to reduce the taps.
Let me quickly explain:
Here's an example for a complex baseband digital signal; already
sampled at a sampling rate of f_sample
What you see there is, across the a horizontal axis denoting the
frequency within your signal, how much power there is for each
"blot" of frequency; a "power spectral density" (PSD); we
typically call this a "Spectrum".
Now, you'll notice that your signal spectrum is periodic – it
repeats every multiple of f_sample. In complex baseband, we
typically "try really hard to forget that" and just deal with one
of these repetitions – the "zero-centered" (hence the name,
baseband) swath from -f_sample/2 to +f_sample/2 (darker green).
As you can infer from that repetition, a discrete-time signal
(so, any signal that you deal with in GNU Radio: signal is
represented by values, so-called samples, one after the other, not
by some smooth function) can only hold frequency content if the
whole represented signal fits inside the sampling rate –
otherwise, due to the periodicity, something from another
repetition "zone" (say, from the –3/2 f_sample to - 1/2 f_sample
zone) overlays your original zone. We call that phenomenon
"aliasing", by the way.
That's exactly what happens when you reduce the sampling rate.
Say, we throw away every even sample, and get half as many samples
per second. What happens? We halfed the number of samples, so we
halfed the sampling rate; we should just be able to relabel the
horizontal axis, right?
But wait, we've just learned that the spectrum repeats every
sampling rate multiple – now f_sample,new; and we see that in the
spectrum, also (now in blue):
Uh-oh. Now the green original and the blue repetitions overlap,
within our nice -f_sample,new / 2 to +f_sample,new / 2 baseband.
That's not usable anymore!
So what the clever signal processing person does is go back and
first low-pass filter the original signal to the part that will
not overlap. We know how wide that part can be: as wide as the new
sampling rate, so in this case, half the original bandwidth:
and now throwing away every other sample, i.e., reducing the
sampling rate to its half:
Oh neat, no spectral overlapping!
Coming back to what your resampler does: It is a "filter to the
new 1/M bandwidth, then throw away every but the M. samples"
block. When set to decimation = 2 (so, M=2), it does what you see
above!
But, your decimation is M=800. That means the filtering needs to
first restrict the green signal to 1/800 of its original
bandwidth. Doing that filtering takes a very complicated (long)
filter. If you ever heard of the Heisenberg uncertainty principle,
that you can't know the impulse (hence the frequency) of a
particle and its location at the same time more exactly than a
specific constant, the same math underlies this principle: narrow
filters, or more precisely, filters that are very sharp in the
frequency domain, need to be very long and drawn out in the time
domain.
So your filter is 27861 taps long – and GNU Radio fails to
construct a method of getting so many samples for a single
iteration of the filter into the filtering, so it tells you "hey,
you want only sample packets of at least 27862 samples, but the
most I could offer you at once is 8192, sorry, this can't work
out".
**How to solve it**, now, is realizing that you don't need to do
all this at once. How about you do
--> resampler decimation=8 --> resampler decimation=4
--> resampler decimation=5 --> resampler decimation=5
That achieves the same result, decimation by 8·4·5·5=800 but with
much shorter filters (and more of these filters can also run at a
lower sampling rate, which is also computationally cheaper).
Cheers,
Marcus
On 24.11.23 07:28, Al Grant wrote:
I am still trying to learn how GR works.
Coming from Java the idea of being able to do some processing there
interests me.
So I am trying to use a baseband file from SDR++ as a file source, and
process it in such a way that I can get the amplitude in Java. I
presume this would mean reading in the bin file and decoding the bits
to the I and Q values.
The source file is an unmodulated pulse on about 160.7807Mhz about 2
times per second.
Here is my block setup: https://imgur.com/a/B2HqCKc
And a link to the github project with the baseband file :
https://github.com/bigalnz/java_test
The issue I am currently having :
block_executor :error: sched: <block
rational_resampler<IN_T,OUT_T,TAP_T> (1)> is requesting more input
data than we can provide. ninput_items_required = 27862
max_possible_items_available = 8191 If this is a filter, consider
reducing the number of taps.
What is going on here and how do I fix this?
Thanks
Al
