Re: Rational Resampler - block executor error

[Marcus Müller]

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
>
>