Re: [Discuss-gnuradio] Obtaining the original (source) samples at the end of the chain (sink)

[Marcus Müller]

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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio