Re: Rational Resampler - block executor error
Thanks Marcus. Time to put this to the test: https://imgur.com/a/hRsYAFu I need a way to test that the values I detect in java are the same values that I get in GR. I tried a Message Debug connected to the output of "Complex to Mag" but that gave me a red arrow so not allowed. Any suggestions? Thanks A On Tue, Nov 28, 2023 at 2:07 AM Marcus Müller wrote: > > Hi Al, > > On 27.11.23 06:44, Al Grant wrote: > > Thanks for the detailed reply Marcus. > > you're most welcome! > > > *M=800* > > Where is M=800 in my rational resampler? I see looking at the link to the > > picture I posted I had Decimation=100 (is M shorthand for decimation?) > > https://imgur.com/a/B2HqCKc shows "Rational Resampler" with "Decimation: > 800", not 100. > > > *PICTURE* > > To your picture: > > > > [image: image.png] > > > > But my sample only has a repeating tone on 1 frequency, but in the picture > > above with frequency on the x axis (and power on the y?), and 3 peaks I > > have circled in red, at first glance I would have said this shows a signal > > on the 3 different frequencies? > > No, it doesn't have 3 different frequencies! You missed my point there: this > is *one* > signal. The frequency axis extends to - infinity and to + infinity; there's > infinitely > many (light green) repetitions, not 3, in a discrete-time signal. (I just > couldn't draw > infinitely wide pictures!) > We just conveniently decide that, to look at the signal, it suffices to look > at the > baseband one repetition, the dark green one. > > It does suffice to describe all the information in the signal! But: it breaks > down when > you do things like decimating or interpolating, because suddenly you get the > effects of > these repetitions you "just tried very hard to forget about" :D > > > I am assuming you didn't mean what I have written above, but I > > can't reconcile the picture with the concept you are trying to convey. > > Hope the above helps! > > > > *FILTER TYPE* > > I see you have suggested a series of resampling filters, instead of 1 big > > one, is that for computing efficiency or because it wont work the way I > > expect the way I have done it? > > > > What is the difference between just a straight decimating block and > > rational resampler? > > If you choose to use a filter that cuts out the lower 1/M of the original > bandwidth, it's > the same. (assuming the rational resampler is set to "Interpolation: 1") > > > *BASEBAND* > > Since my original post I have a slightly better understanding of a baseband > > file. Correct me if I get it wrong, but for example a RTL-SDR can capture > > baseband at 2.4Mhz (i.e. spectral width). > > Sounds right! > > > To my example I am interested in > > 160.100Mhz to 160.200 with 100 channels spaced at 160.100, 160.110Mhz etc > > etc. > > So, a bandwidth of 100 · 0.01 MHz, if I get you correctly, or 1 MHz. Add a > bit "left and > right", because the analog filters aren't perfect, so maybe 1.2 MHz, just > because we can > trivially afford to be so generous. > > > So in one baseband file I can capture all 100 channels. Cool. > > Exactly! > > > For the moment I just want to focus on 1 disaster (channel) at a time, and > > am interested in getting the file into Java and doing the processing there. > > And you seem to be doing the right thing in principle (I didn't look at the > numbers being > sensible here): you're selecting a single channel, say "OK, because that > channel is only > 1/M of the overall bandwidth, I decimate by M". > > The thing I'm not understanding about your flow graph is then why the > following low-pass > filter at all? > (it's also incorrectly parameterized, as far as I can tell, because your > input sampling > rate wasn't 32 kHz (as specified in the low-pass filter) times 800 (=25.6 > MHz) (or 100, > assuming the 800 was a typo, so 100·32 kHz = 3.2 MHz), but probably a > bandwidth that your > RTL dongle actually supports.) > > > Best regards, > Marcus > -- "Beat it punk!" - Clint Eastwood
Re: Rational Resampler - block executor error
Hi Al, On 27.11.23 06:44, Al Grant wrote: Thanks for the detailed reply Marcus. you're most welcome! *M=800* Where is M=800 in my rational resampler? I see looking at the link to the picture I posted I had Decimation=100 (is M shorthand for decimation?) https://imgur.com/a/B2HqCKc shows "Rational Resampler" with "Decimation: 800", not 100. *PICTURE* To your picture: [image: image.png] But my sample only has a repeating tone on 1 frequency, but in the picture above with frequency on the x axis (and power on the y?), and 3 peaks I have circled in red, at first glance I would have said this shows a signal on the 3 different frequencies? No, it doesn't have 3 different frequencies! You missed my point there: this is *one* signal. The frequency axis extends to - infinity and to + infinity; there's infinitely many (light green) repetitions, not 3, in a discrete-time signal. (I just couldn't draw infinitely wide pictures!) We just conveniently decide that, to look at the signal, it suffices to look at the baseband one repetition, the dark green one. It does suffice to describe all the information in the signal! But: it breaks down when you do things like decimating or interpolating, because suddenly you get the effects of these repetitions you "just tried very hard to forget about" :D I am assuming you didn't mean what I have written above, but I can't reconcile the picture with the concept you are trying to convey. Hope the above helps! *FILTER TYPE* I see you have suggested a series of resampling filters, instead of 1 big one, is that for computing efficiency or because it wont work the way I expect the way I have done it? What is the difference between just a straight decimating block and rational resampler? If you choose to use a filter that cuts out the lower 1/M of the original bandwidth, it's the same. (assuming the rational resampler is set to "Interpolation: 1") *BASEBAND* Since my original post I have a slightly better understanding of a baseband file. Correct me if I get it wrong, but for example a RTL-SDR can capture baseband at 2.4Mhz (i.e. spectral width). Sounds right! To my example I am interested in 160.100Mhz to 160.200 with 100 channels spaced at 160.100, 160.110Mhz etc etc. So, a bandwidth of 100 · 0.01 MHz, if I get you correctly, or 1 MHz. Add a bit "left and right", because the analog filters aren't perfect, so maybe 1.2 MHz, just because we can trivially afford to be so generous. So in one baseband file I can capture all 100 channels. Cool. Exactly! For the moment I just want to focus on 1 disaster (channel) at a time, and am interested in getting the file into Java and doing the processing there. And you seem to be doing the right thing in principle (I didn't look at the numbers being sensible here): you're selecting a single channel, say "OK, because that channel is only 1/M of the overall bandwidth, I decimate by M". The thing I'm not understanding about your flow graph is then why the following low-pass filter at all? (it's also incorrectly parameterized, as far as I can tell, because your input sampling rate wasn't 32 kHz (as specified in the low-pass filter) times 800 (=25.6 MHz) (or 100, assuming the 800 was a typo, so 100·32 kHz = 3.2 MHz), but probably a bandwidth that your RTL dongle actually supports.) Best regards, Marcus
Re: Rational Resampler - block executor error
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 =
Rational Resampler - block executor error
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 = 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
