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
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
