On Thu, Aug 4, 2016 at 9:43 AM, Sebastian Müller wrote:
> Hi Kevin,
>
> the problem arises since my blocks detect signals in the spectrum and
> estimate their bandwidth. Then, each signal gets filtered and decimated to
> the needed sample rate according to Nyquist-Shannon. This sample rate is
> w
Hi Kevin,
the problem arises since my blocks detect signals in the spectrum and
estimate their bandwidth. Then, each signal gets filtered and decimated to
the needed sample rate according to Nyquist-Shannon. This sample rate is
well defined, but only known during runtime.
Regards
Sebastian
2016-
On Wed, Aug 3, 2016 at 8:29 AM, Sebastian Müller wrote:
> 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
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
rec
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*
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 run
