discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rational resampler does not change behaviour when changing the decim


From: Jeff Long
Subject: Re: Rational resampler does not change behaviour when changing the decimaton rate
Date: Sun, 28 Nov 2021 15:51:08 -0500

This is true. The buffers are allocated when the flowgraph starts, and buffer size depends on relative rate. So, no luck getting this changed soon.

On Sun, Nov 28, 2021 at 3:46 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:
On 2021-11-28 12:21, Jeff Long wrote:
Sure, you can use a single tap. You will end up with aliasing when you decimate.

I'd call the addition of run time modification of the RR a feature request, not an issue. Either way you can put it on the github issue tracker. No promises until someone looks at how easy it is to change.

My understanding is that "sync decimator" blocks, of which this may be one, cannot have their decimation ratio changed at run-time. It's a scheduler thing.  But my
  impression may be years out of date at this point.


On Sun, Nov 28, 2021 at 11:28 AM Fernando Peral <fernando@samara.com.es> wrote:
On 28/11/21 13:09, Jeff Long wrote:
Any field that is underlined may be changed at run time. Fields that are not underlined can not be changed at run time, and will remain at the value they had when the flowgraph started.

Then, I understand that when I use the rational resampler with no taps specified it should work same way as the fractional resampler does, when changing the decimation value, so it is an issue I must report


Also, keep in mind that taps typically depend on the resampling ratio. If no taps are specified for the rational resampler, it generates its own based on the other 3 parameters, but if the user provides taps, changing the ratio at run time may not give the expected result.

The decimating FIR filter can't be used without specifying taps, as it stops reporting an error, but I can use it with taps=1... I mean with that that is a all pass filter doing only the decimation, is that correct?







On Sun, Nov 28, 2021 at 3:55 AM Fernando Peral <fernando@samara.com.es> wrote:
I gues you said   that taps being underlined  means that decimation can't be changed at run time.
I have tested the same diagram with decimating FIR filter, rational resampler and fractional resampler, with the third one it works like I wanted, it change in runtime, with the other two (both of them have a underlined taps) it don't.




On 28/11/21 2:58, Jeff Long wrote:
You are correct. Note that in the params dialog, only "taps" is underlined. This means that decimation can be changed at runtime.

I'm not sure whether there is an easy change that can be made to support what you want. If you feel this is important, please add a feature request as an issue (https://github.com/gnuradio/gnuradio/issues).

On Sat, Nov 27, 2021 at 7:53 PM Fernando Peral <fernando@samara.com.es> wrote:

I'm using the following  diagram to test it, where

the first freq sink (x1) has bandwidth fixed to samp_rate/1  and its rational resampler have decimation fixed to 1

the second freq sink (x2) has bandwidth fixed to samp_rate/2  and its rational resampler have decimation fixed to 2

the third freq sink (x5) has bandwidth fixed to samp_rate/5  and its rational resampler have decimation fixed to 5

the fourth freq sink (variable) has bandwidth fixed to samp_rate/decimation  and its rational resampler have decimation fixed to decimation




I run the diagram, decimation default value is 1 and all seems to work


Then I change  decimation in the GUI Range  and the variable block don't work



Then I stop the diagram, change the default value of the GUI range to  2



I run it again .... it works



Then I change the value of decimation in the GUI range ....  and it does not work



The x axis change but the "image" don't ...   what am I doing bad?









reply via email to

[Prev in Thread] Current Thread [Next in Thread]