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
Figure 1: Spectrum of a discrete-time signal
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?
Figure 2
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):
Figure 3: Now with aliases!
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:
Figure 4: Low-pass filtered (to half bandwidth) original signal at original
sampling rate
and now throwing away every other sample, i.e., reducing the sampling rate to
its half:
Figure 5: Low-pass filtered (to half bandwidth) original signal at half
sampling rate
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: (1)> is requesting more input
data than we can provide. ninput_items_required = 27862
max_possible_items_available =
