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