Hi Veljko,
> The problem is, in the process of filtering, demodulation and
> evaluation I lose the original samples.
Hm, "I lose the original samples" is kind of philosophical: I personally
like to look at signal processing like it's a process of refinement, so
I wouldn't "emotionally" agree with you here. Of course, you don't
inherently have the upstream samples with you, so I technically agree.
> If, at the point of detection
> I go back and fetch samples from USRP, those won't be the exact
> samples corresponding to the generated result.
Of course, if the blocks between the USRP source and your detector
consume the samples on their input, GNU Radio has no reason to keep them
and lets the USRP overwrite consumed items with fresh ones.
But: Why would you want to go back?
Assuming you want to look at the unprocessed spectrum later on, you'd
just have a file_sink in parallel to your detector chain. You just take
note of the sample numbers at which you detected an event, from which
you can, under certain conditions, calculate the point (or the range) in
time when your event happened on the input stream.
> Moreover, since the
> delay the original samples take to go through the processing chain is
> varying and unpredictable (I learnt that in my last experiment, and
> thank you Macus for explaining this),
What, no!
You're mixing things up: The /wall clock temporal relations/ between
blocks are random, but of course if you've got a flowgraph like
/--->multiply_const---> sink A
source --|
\--->add_const--->multiply_const---> sink B
where every block generates exactly as many output samples as it
consumes input samples (that's called a /sync/ block in GNU Radio, btw),
the first sample reaching sink A is based on the same source sample as
the first sample reaching sink B. /Wall clock delay/ might be different
and of course is not zero, but that's not really of interest here --
/signal delay/ is only relevant regarding to the sample count -- and
that delay is 0, on both chains, here, because there are no mathematical
operations introducing delay.
Now, delay 0 is a special case, and to illustrate:
/--->multiply_const---> sink A
source --|
\--->FIR Filter---> sink B
Both, multiply_const and FIR filter are sync blocks, i.e. they produce
as much output samples as they consume input; but:
The DSP delay of the filter is probably not 0; for example, take a FIR
filter with the taps:
[0 0 0 0 1 0 0 0 0]
That's a bit of a useless filter, because it just gives you the exact
input signal as output, but it delays it by 5 samples.
So the first sample reaching sink A looks a lot like the fifth reaching
sink B.
> I can't just build a parallel
> chain that will merely delay the samples, and then fetch those delayed
> samples.
Usually, i.e. in a detector chain that makes sense, that is possible.
You will just need to know the delay of each block involved.
Best regards,
Marcus
On 26.10.2015 15:26, Veljko Pejovic wrote:
> Hi,
>
> I would like to process samples from a USRP (let's use FM
> demodulation, for example) and then identify which of the original
> samples correspond to a particular result at the end of the chain
> (say, a beginning of a stereo transmission, a beginning of a song,
> etc.).
>
> The problem is, in the process of filtering, demodulation and
> evaluation I lose the original samples. If, at the point of detection
> I go back and fetch samples from USRP, those won't be the exact
> samples corresponding to the generated result. Moreover, since the
> delay the original samples take to go through the processing chain is
> varying and unpredictable (I learnt that in my last experiment, and
> thank you Macus for explaining this), I can't just build a parallel
> chain that will merely delay the samples, and then fetch those delayed
> samples.
>
> So, what is the solution? One idea I have is to extend each block in
> the processing chain with another input/output port and carry along
> the original samples. Then, in the end, when I evaluate the result, I
> can just take the piggybacked samples, and be sure that those are the
> ones that generated the result. However, this means I have to modify
> each block in the chain. Is there a more elegant solution to the
> problem?
>
> Thanks,
>
>
> Veljko
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
