|
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 |
On 2021-11-28 12:21, Jeff Long wrote:
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 mySure, 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.
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?
[Prev in Thread] | Current Thread | [Next in Thread] |