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

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