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

[Veljko Pejovic]

Thanks Marcus, Jeon,

I understand the misconception I've had about time vs samples.

Since I want to get the original samples that correspond to the
processed ones (corresponding to a particular value at the end of the
chain), I believe there are two ways I can proceed:

1) find out what is the delay (in samples) between the processing
chain, and the other chain (that doesn't process anything, but merely
carries the original samples), and then introduce a delay element in
the "carry original samples" chain, so to get both the processed
result and the original sample that generated the result at the tick
at the sink.

2) tag samples at the source and once I get a result of interest at
the end of the processing chain, identify the original sample with
that same tag.

I think that approach 2) makes more sense, however, I am not sure how
to implement tagging properly. I check the link that Jeon has posted,
and I tried simple strobe tagging in GRC. It works well, tags
propagate through the processing chain. Yet, what I need is a unique
tag for each sample. I suppose I would have to write my own block for
that? Or, is there already some sort of an ID/counter associated with
each sample coming from a USRP?

Thanks,

Veljko

On Mon, Oct 26, 2015 at 6:02 PM, Marcus Müller <address@hidden> wrote:
> 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
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>