Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels

[Matteo Campanella]

There is no forecast method implemented, and the main cycle is structured
so that it is impossible to consume more than offered from scheduler (see
http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00253.html
for code posting).

The first version of the code is working more or less like this:
when not in sync mode (still looking for sync), the distance between
subsequent zero crossings is continuously measured (therefore consuming
signal samples), until a valid time interval is found - at that point
another cycle is started that examines the clock input samples till a
transition is found, and consumes all the samples before the transition
one;  at this point the new synced state is entered where the clock and
the signal are synced, and they are consumed synchronously from now on.
Debugging revealed that averagely it took hundredths of samples on the
signal side to find correctly spaced zero crossings and only tenths of
clock samples to find the first transition; upon these conditions clock
samples were not consumed correctly: if the transition was at sample #43
and I issued consume(43), then next work call was not presenting sample
#44 for clock as the first clock

(http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00253.html
carries the code of the work method and the gnuplot files that show what
happens before and after consume)

Then I thought to change the quest for clock transition so that it was not
starting from sample #1, but from one much closer in time to the sample of
signal where it was recognized as valid; that is, if I had valid signal @
sample #873, I now search a clock transition NEAR sample #873, and
therefore I consume more or less the same amount of samples from both
channels. This seems to works fine and from debugging I ALWAYS get clock
transition in sync with symbol start.

regards
Matteo

> On Tue, Jan 02, 2007 at 07:59:00PM +0100, Matteo Campanella wrote:
>> Hi everyone, on Dec 25th I posted a message about a possible strange
>> behaviour of consume in a block where there are two inputs and samples
>> are
>> consumed at different rates; in order to further check the nature of the
>> problem, I changed to code so that the clock input was checked for a
>> transition in the latest period, rather than since the beginning; that
>> way,
>> consume for the clock input consumed almost the same number of samples
>> as
>> the signal input - I made similar graphs to the ones I posted on 25th,
>> and
>> this time everything seems to work ok, that is, samples consumed are the
>> same number as requested with the consume() call. So this further test
>> makes
>> me believe that something bad happens if in the general work I consume
>> 1000
>> samples of one input and just few, let's say 30, of another. Should it
>> be
>> like that? Or is there something wrong?
>>
>> regards, hny
>> Matteo iz2eeq
>
> I believe that consume works as expected.
>
> You may want to confirm that you are not eating more input that is
> actually valid.  What are you using for your forecast method?  Does it
> compute a reasonable answer given your circumstances?
>
> Eric
>
>