Re: [Discuss-gnuradio] synchronization between blocks

[Michael Dickens]

Hi Nemanja - Non-sync blocks -- ones that do not guarantee some number of 
output items given some number of input items -- cannot be assumed to have 
constant sample delay from input to output (or, in any other way; though they 
may have this property).  This property is irrespective of what the block's 
"forecast" method returns.  The GR scheduler correctly will handle whatever 
data is created so long as it is <= noutput_items, irrespective of whether if 
it meets the forecast or not.

In your example, you have:

Path #1 : [throttle] -> RMS -> log10 -> DELAY -> {Clock Sync}

Path #2 : [throttle] -> LPF -> QD -> IIR -> Min/Max Threshold -> {Clock Sync}

where [] is the path's source and {} is the sink for both paths and hence we 
don't look at those.  

If you have 1 path that uses only sync blocks, then the sample delay from the 
"source" to "sink" (the blocks generating data for this path and consuming data 
from this path) will be a deterministic constant.  Path #1 looks to be fully 
sync to me, with a sample delay of DELAY's samples since RMS and log10 are both 
1:1 (#inputs:#outputs) with no delay, and DELAY is 1:1 but with "DELAY" samples.

If you have another path (from the same source to the same sink) with a 
non-sync block in it, then the sample delay in that specific path is not 
guaranteed to be a deterministic constant (though it may be).  In your Path #2, 
the first 3 blocks are all sync types.  If the "Min/Max Threshold" is anything 
like "plateau_detector_fb", then it is not a sync block.  So, the sample delay 
for LPF -> QD -> IIR will be a constant, but the Threshold block makes the 
overall path non-sync.

So, because you don't have fully sync processing, you cannot just add a delay 
in 1 path to get the sample delay difference to 0 -- it might work sometimes, 
but it is not guaranteed to work all of the time.

There is probably a way to keep cross-path sample sync, but it won't be trivial 
to implement I would guess, and it is likely application dependent.  Good luck! 
- MLD

ps> Just to be complete: The "real-world clock" sample delay (time in seconds) 
will not be deterministic no matter the block type (sync or non-sync).  This 
value depends on the algorithm being used, the amount of data being processed, 
hardware (CPU speed / type / memory / caches), and OS (affinity, real time, 
context switching).

On Feb 4, 2014, at 3:59 AM, Nemanja Savic <address@hidden> wrote:
> Well, I think the problem comes from the block which is not of sync type. 
> INputs to this block are demodulated signal and the very input signal, and 
> the output are sybol values and signal value at the point of sampling.
> 
> However I will try with logging and see what can I find. But just for 
> clarification, can the problem come from forecast function where I ask for 
> the same amount of input samples as the number of output samples (which is 
> like with sync block), but I produce like 20 times less?