Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Jan 29, 2014 at 4:04 AM, Nemanja S. [email protected]
wrote:
it has 331 taps. So when I set delay to 331, the signal are not aligned. Is
delay between this two paths constant during execution or not?Best,
–
Nemanja Savić
Yes, the delay is constant. But you’ve set the wrong value. For a
symmetric
FIR filter like you are using, the delay is (N-1)/2.
Tom
Thank you Tom. The problem is that in the configuration that is attached
delay must be arround 600 in order to allign two paths. Next I put a
complex delay block in the second path just after the theottle (and
removed
the existing one) and it works fine with 330 (not perfectly alligned but
ok). Is there any other sources of delay that should be accounted.
Hi all again,
at the moment I thought that the problem was solved, but actually
something
strange is going on. I would only like to ask whether delay between two
paths can roll out somehow (i don’t know if this verb exists). The point
is
that at the beginig of the execution, it looks like the script is doing
fine, but then I realize signs of unalligned signals which I can’t in
some
other way.
Best
Nemanja
Thank you Michael.
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?
Best regards
On Feb 3, 2014, at 10:14 AM, Nemanja S. [email protected] wrote:
at the moment I thought that the problem was solved, but actually something
strange is going on. I would only like to ask whether delay between two paths can
roll out somehow (i don’t know if this verb exists). The point is that at the
beginig of the execution, it looks like the script is doing fine, but then I
realize signs of unalligned signals which I can’t in some other way.
IIRC: Because of the way GNU Radio internally handles data processing
(it waits for data upstream to become available before -starting-
processing for a given block), and since -your specific graph- contains
only sync blocks (yes?), then the sample delay difference between the 2
branches of -your specific graph- should be constant. Further, it
should be the same constant for every graph execution.
If any blocks within a specific path are not sync blocks, e.g., a packet
decoder, then the sample delay difference is not guaranteed (constant or
otherwise).
The wall-clock delay difference will not be constant; it can be any
non-negative (and, generally > 0) time.
All of the above said: If you’re into compiling GNU Radio, you can go
into gnuradio-runtime/lib/block_executor.cc and set “ENABLE_LOGGING” to
- Recompile/reinstall GNU Radio, then when you execute your graph
you’ll get a printout dump of what each block is doing. That printout
might help you debug this issue; or, not. You might also add LOG
messages in that file which could help … maybe; or, not.
Hope this helps! - MLD
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).