Re: [Discuss-gnuradio] Scheduler Help/Question

[Johnathan Corgan]

On Tue, Jan 6, 2009 at 5:43 AM, Earle Frank <address@hidden> wrote:

>> The bug is that D should always produce an enable output, 1:1 with the
>> input.  If you're not sure of the state at start up time, output a
>> reasonable default value.
>>
>
> I guess I would agree with your 1:1 statement if I was using a
> gr_sync_block.  And I may not have previously said this, but I am using a
> gr_block. My understanding of the gr_block does not need a 1:1 input:output.
> Is that incorrect?
>
> My block D can not always produce an enable output.  Block D must see the
> complete event occur.  Then the block determines if the event was a valid
> event.  This can only be determined after the event is finished.  At that
> time if Block D sees a valid event, then the enable signal is output high
> for the time matching the event.  Otherwise the block outputs low for that
> time.
>
> With this operation of block D, is it not possible to work in the framework
> of GNURadio?

I'm not convinced Eric's analysis is correct, but that would only be
because I don't think there is enough information in your description
to accurately determine the problem.  There is no reason, however,
from what you've described, that it shouldn't be possible to implement
in GNU Radio.  Without looking at the actual code, we can't tell
whether there is a topology problem, a bug in the assumptions that a
work function is making, or something else.

What I suspect is that you need to introduce a sample delay on one of
the paths to match the pipeline delay of block D.  That way the two
streams converge on the final block at the right "time".  Block E
probably makes the assumption that it needs to consume equal amounts
of items on each input; if one leg has more pipeline delay, the
scheduler will be looking for it to produce more samples to match the
number of samples consumed from the other leg.

But this is just a hunch based on what I've heard so far.

-Johnathan