[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitp

From: Matteo Campanella
Subject: Re: [Discuss-gnuradio] strange consume behaviours on blocks with mulitple input channels
Date: Wed, 3 Jan 2007 10:31:02 +0100 (CET)
User-agent: SquirrelMail/1.4.8-1.fc5

I have attached the source file where the work method is contained. I
cannot make any assumption on delta - it can be even or odd, the loss of
precision because of the division by two is not going to be a problem
though as there are many hundredths of samples per symbol (input sample
rate to block is 256kbps). More, the consume on the signal works, infact
on the next work invocation I get the signal samples the right way - the
problem is on the clock cycle:

// From this point sync clk
d_sign_last = (clk[0] > 0 ? 1: -1);
for (i = 0; i < n_clk_in ; i++) {
   sign_current = (clk[i] > 0 ? 1: -1);
   if(sign_current != d_sign_last) {
     // zc in clock
     consume(1, i);
   d_sign_last = sign_current;
return 0;

here I would expect to consume clock samples up to the first sample after
level transition; however if I graph clock on the next work               
                run, clock is NOT a the transition point.

If I change the code this way:

d_sign_last = (clk[i] > 0 ? 1: -1);
...code as above follows...

so that search for clock transition is done not starting from sample #0,
but from a sample somehow near to where I actually am on signal so that
consume on channel 1 will be similar (in number of samples to consume) to
consume on channel 0, then I experience correct sample consuming and
clock/signal alignment on the next work cycle.

Matteo iz2eeq

> On Wed, Jan 03, 2007 at 09:32:06AM +0100, Matteo Campanella wrote:
>> 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 code's a little hard to follow in the archive.  However, this
> piece of code looks potentially suspicious.  Is delta always even, or
> always odd?  Are you sure that this is correct?
>   consume(0, i-(delta/2));
> Eric

Attachment: gr_rds_biphase_decoder.cc
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]