Re: [Discuss-gnuradio] Re: Problem with FIR filter

[Eric Blossom]

On Thu, Jul 22, 2010 at 05:13:09PM +0100, John Wilson wrote:
> So does no one have any idea about this? It doesn't seem like it should be
> too difficult to solve, I've worked around the problem for the simulations
> I'm currently running but it's a shame as it reveals a fundamental
> incapacity for GNU Radio to perform some other interesting simulations and
> techniques, notably (for me at least) in the area of repeat requests.
> Currently I'm implementing a type II HARQ repeat request system by
> dynamically reconfiguring a flow graph during operation, this makes use of
> the run() command a lot but if every time I run this command every filter in
> the system is reset it's going to make it almost impossible to implement.

Part of the challenge in implementing dynamic reconfiguration is what
to do with any intermediate samples left over in the buffers.  This
brings up questions such as do the blocks own the buffers?  If so,
does the upstream block own the buffer, or the downstream block?  What
about the cases where there are multiple downstream readers of a
buffer?  What happens if you replace the upstream block?  What about
the downstream block?

With regards to the FIRs, I think what you're seeing is a side effect
of our decision to implement the delay line implicitly. That is, it's
handled using the "history" mechanism, and involves pre-stuffing the
input buffer with zeros.  The chief advantage of this strategy is
performance.  This idea combined with the our zero copy MMU circular
buffer trick, means there are no corner cases in the implementation of
the FIRs (no "end-of-buffer wrap around" etc.) and no cycles are
expended storing anything in any delay line.  (Having versions of the
FIRs that explicity handle a delay line is definitely possible.)

I understand that you're relating with this like it's a serious bug,
but I think it would be more productive if you would specify exactly
the behavior that you want, see if that spec is consistent with
expectations that other folks may have (for their own good reasons),
and then we could discuss where in the code the modifications would
go.

A related question is when (if ever) should runtime state (both
external to a block, like the buffers) and internal state (say PLL
state inside of a block) be reset.

I can see use cases arguing for a number of models.  It basically
depends on what you are trying to do.

So, how would you want it to behave?

Some of the primitive operations to consider are tb.start(),
tb.stop(), tb.wait() and tb.run() == { tb.start(); tb.wait(); }

Adding a "reset" method to gr_basic_block is also possible.  Of course
then you need to figure out when the runtime (or user) should call it.

When using lock/unlock for dynamic reconfiguration, the internal
represenation of the graph is actually reconfigured in the midst of
the final unlock, and that code uses start() and stop() to pause the
action in the graph while it shuffles everything around.

Again, I think your question/complaint is valid, and figuring out the
desired behavior at all the corner cases is important.  Then of course
there's figuring out how to implement it :-)

If you get a chance, please have a go at it.

Eric