[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuradio-discuss
Subject:    Re: [Discuss-gnuradio] Interpolating FIR filter with runtime adjustable interpolation value
From:       Kevin Reid <kpreid () switchb ! org>
Date:       2017-06-28 14:25:49
Message-ID: CANkSj9U+UtGfb3y7nOu55dspe4t83DGPoG9BNqRo5D2N8vByCQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tue, Jun 27, 2017 at 4:16 PM, Joe K <radix99@gmail.com> wrote:

> In reality my interpolating filter is part of a Python-based hierarchical
> block, which is based off of the gmsk_mod in gr-digital.  I'm essentially
> trying to decouple my symbol rate from the hardware sample rate by
> adjusting the modulator's samples/symbol factor in real time.  I tried
> using lock/disconnect/create new filter/connect/unlock but I randomly get
> hangs on the unlock step.  When it does get past unlocking the output is =
as
> expected.
>
> I remembered a bug report about unlock hanging, which was supposedly
> fixed.  Is it legit to lock/etc/unlock within a hierarchical block?  Is i=
t
> a known problem for it to hang on unlock() within a hierarchical block?
> This is GR 3.7.11.
>

I work on an application which makes heavy use of flow graph
reconfiguration and I have several times found issues with specific blocks.
If you can narrow down the source of the issue into a good reproduction
test case and report or fix the bug, I for one would appreciate the
contribution to GR's stability.

Another possibility, though, is that if your flow graph has signal paths
which split and rejoin, then replacing blocks on one of the paths *may* end
up with a configuration of buffer fullnesses which deadlocks (and if it
does not, then it will anyway not have the phase synchronization you might
hope for). There is no way to avoid this but rebuilding both paths at once.

As to your original issue, there has previously been discussion of variable
rate resampling in the context of allowing audio sinks/sources to adapt to
follow RF clocks. I don't think any implementation work has been done =E2=
=80=94 I'm
just mentioning that there is interest in having a solution to the general
problem.

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 27, 2017 \
at 4:16 PM, Joe K <span dir="ltr">&lt;<a href="mailto:radix99@gmail.com" \
target="_blank">radix99@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>In reality my \
interpolating filter is part of a Python-based hierarchical block, which is based off \
of the gmsk_mod in gr-digital.   I&#39;m essentially trying to decouple my symbol \
rate from the hardware sample rate by adjusting the modulator&#39;s samples/symbol \
factor in real time.   I tried using lock/disconnect/create new filter/connect/unlock \
but I randomly get hangs on the unlock step.   When it does get past unlocking the \
output is as expected.<br></div></div></div></div><br>I remembered a bug report about \
unlock hanging, which was supposedly fixed.   Is it legit to lock/etc/unlock within a \
hierarchical block?   Is it a known problem for it to hang on unlock() within a \
hierarchical block?   This is GR \
3.7.11.<br></div></div></div></blockquote><div><br></div><div>I work on an \
application which makes heavy use of flow graph reconfiguration and I have several \
times found issues with specific blocks. If you can narrow down the source of the \
issue into a good reproduction test case and report or fix the bug, I for one would \
appreciate the contribution to GR&#39;s stability.</div><div><br></div><div>Another \
possibility, though, is that if your flow graph has signal paths which split and \
rejoin, then replacing blocks on one of the paths <i>may</i> end up with a \
configuration of buffer fullnesses which deadlocks (and if it does not, then it will \
anyway not have the phase synchronization you might hope for). There is no way to \
avoid this but rebuilding both paths at once.</div><div><br></div><div>As to your \
original issue, there has previously been discussion of variable rate resampling in \
the context of allowing audio sinks/sources to adapt to follow RF clocks. I don&#39;t \
think any implementation work has been done — I&#39;m just mentioning that there is \
interest in having a solution to the general problem.</div></div></div></div>



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


[prev in list] [next in list] [prev in thread] [next in thread]