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
On Tue, Jan 02, 2007 at 07:59:00PM +0100, Matteo C. wrote:
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
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
([Discuss-gnuradio] strange consume behaviours on input channels
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
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);
break;
}
d_sign_last = sign_current;
}
enter_locked();
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:
i=i-(delta/2);
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.
regards
Matteo iz2eeq
On Wed, Jan 03, 2007 at 09:32:06AM +0100, Matteo C. 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
[Discuss-gnuradio] strange consume behaviours on input channels
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
// 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);
break;
}
d_sign_last = sign_current;
}
enter_locked();
return 0; // No output produced, but now sync...
The break after consume may be incorrect. If it’s executed you do not
set d_sign_last to the new sign (sign_current).
Eric
d_sign_last = sign_current;
If the break is executed, we have clock and signal aligned;
enter_locked()
and return are executed after break and on next work invocation we will
be
in the sync state, that is the other case of the switch.
Matteo