Re: [Discuss-gnuradio] Resampler with changing rate during runtime

[Sebastian Müller]

Hi Marcus,

thanks for the answer! Though to be honest I'm not really happy with that solution. This simple "FM demod" thing is getting real complicated here. We would need 4 blocks just for demodulating FM in your proposed scenario:

(msg->[some resamp rate calc block]->[frac resampler]->[WBFM receive]->[Audio Sink]).

My mentors and me had a hangout today and decided to create an instance of the fractional resampler block within the Extractor block of my toolbox. My block will then emulate the scheduler. This way, when extracting a signal out of the combined messages of the Separator, one can set a fixed sample rate for each processing chain (which is really nice I think). Also, it can become handy to generally have the possibility of a fixed sample rate in the toolbox standard blocks.

Anyway thanks for your ideas!

Cheers,

Sebastian

2016-08-03 19:44 GMT+02:00 Marcus Müller <address@hidden>:

Ok, so the point is that you want to make run-time changes to an existing block.
The classical solution I'd go for is to put the block (here: resampler) into a hier block, and add something that receives, translates messages, or tags.

On the other hand, really, the fractional_resampler_ff *should* have a message handler that changes the resampling ratio. The fact that there's a method that can just change the ratio while general_work() might be doing its job in a different thread is a multithreading disaster happening right before our eyes. So, if I might be as brazen: please make sure no-one already did this on next, and then just add a message port handler that sets the resampling ration (and one for the $\mu$, if possible), using the "canonical" pmt_dict format (i.e. {"resampling_ratio": pmt_double} or so).

Since you're writing an OOT that you probably want people to use even if they're not using bleeding-edge GR, I'd personally say: copy&paste the resampler block you need from gr-filter to gr-inspector, modify it to your needs and upstream your changes, and also add a remark to your Readme that starting with GR version 3.X.Y, you don't need that block anymore; more responsible upstream developers than I am might have a different view, however.

Cheers,
Marcus

On 08/03/2016 05:29 PM, Sebastian Müller wrote:

Hi list,

I have stumbled upon a problem and I'm not sure what's the best way to deal with it.

My target is to have a FM demodulator for my gr-inspector toolbox. For this, I generally would use a WBFM receive -> Audio sink chain. Now, the quadrature rate and audio decimation are unknown before runtime, but calculated by my other blocks while running. For this purpose, I would like to implement a block, that resamples any given signal to a fixed output sample rate (in this example a bit more than the audio rate). I have messages available that contain the sample rate of my input signal as well as the input signal itself.

My first thought was to use an existing resample block, but I'm not sure how to include it into my own block. Inheriting from the public header yields a compiling error since the methods are not implemented (they are in the ***_impl.h class, which is not public). Is there another way to "remote control" other blocks within my block? Or generally a better solution for my problem?

Thanks for all answers

Cheers

Sebastian

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio