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
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
// 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) {
// 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) {
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
