Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph possible?

[Martin Braun]

On 02/20/2015 12:32 PM, Jorge Gallo wrote:
>     - Say you send a msg to the USRP source after you've received 5 vectors
>     of spectral estimate. The USRP source will already be way ahead of your
>     downstream block, so you could potentially be getting hundreds of
>     vectors to process. They will be tagged, so you can discard them if you
>     like.
> 
> 
> Yes, that is the idea. Since the flowgraph is continuously running many
> unwanted samples will arrive to my tagged file sink after a tune. I will
> discard them until I receive a sample with the correct "rx_freq" tag.

OK; that would work.

>     - The Vector IIR will not know that you've retuned, so you will be
>     "smearing" together vectors that don't belong together. What you need is
>     a form of integrate-and-dump -- maybe the gr-specest toolbox can help
>     you with that.
> 
> I implemented this block in order to do a moving average but as you said
> it is problematic. The average should be done with the samples written
> in the files so that if averaging is needed it will be done by the SW
> which post-processes the written power samples.

That's a way to do it. There's probably many others, but this works.

> Without the IIR block, do you see any problem about mixing of wanted and
> unwanted samples?

No, it's just the memory of the IIR that causes this.

> If I understood it correctly, after a tuning, the USRP source will send
> automatically the "rx_freq" tag so I have to do nothing to implement the
> tag streaming. Is it correct?

Correct!

> Does your new approach have any advantage? I see that the signal
> processing (either approach) will have a host-dependent latency so that
> your "X miliseconds" parameter would have to be calibrated when
> different hosts used. Furthermore by monitoring the number of samples
> written to files I get more control about how much information I write
> in files.

You still need to monitor, any way. But by simply sending a message
every X milliseconds, you're actually *decoupling* the retune time from
host latency, which depends on many things. It might save you some
coding effort, since you may be able to reuse the message generator blocks.

Cheers,
M

> I am open to new  solutions before I program something so any tips are
> more than welcomed.