[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph po
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph possible? |
Date: |
Mon, 23 Feb 2015 18:07:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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.