[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:04:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Sorry, I dropped the ball on this.
All you need is in the most current GNU Radio version. You don't need
gr-extras etc.
Cheers,
M
On 02/23/2015 09:00 AM, Jorge Gallo wrote:
> Hi all, Martin,
>
>
> At this point I got confused about what I need for implementing message
> passing and stream tagging reading capabilities.
>
>
> At first I thought everything was implemented in GNURadio 3.7 (which I use)
>
> http://gnuradio.org/doc/doxygen/page_msg_passing.html
>
> http://gnuradio.org/doc/doxygen/page_stream_tags.html
>
> http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html
>
>
> However I read about different libraries of GNURadio: feval, gr-extras
>
> I got GNURadio 3.7.5 and UHD 3.8. What do I need to start implementing a
> sink block which sends tunning messages to a USRP source block and reads
> tags from the data streaming?
>
>
> Martin, any comments or wrong ideas about my last reply?
>
>
> Many thanks for your support,
>
> Jorge.
>
>
> On 20 February 2015 at 12:32, Jorge Gallo <address@hidden
> <mailto:address@hidden>> wrote:
>
>
> On 20 February 2015 at 10:26, Martin Braun <address@hidden
> <mailto:address@hidden>> wrote:
>
> On 02/20/2015 09:33 AM, Jorge Gallo wrote:
> > Hello,
> >
> > I would like to run a flowgraph similar to the one I attach in a
> > picture. It would work as follows:
> >
> > USRP source would send frames with tags indicating the "rx_freq" of
> > these samples. Then the power of those samples will be calculated.
> >
> > Will the "rx_freq tag" still be present at the input of the Tagged
> File
> > Sink or does any block in the middle get rid of them?
>
> These blocks will keep the tags in there.
>
> > If still present in the Tagged File Sink, this block would store
> centain
> > number of vectors. Lets say 5 vectors of 2048 lenght (this would
> give me
> > 5 power estimations of the current band).
> >
> > When the number of stored vectors reaches a threshold, the Tagged
> File
> > sink would stop storing samples and would send a "center_freq"
> message
> > to the USRP in order to tune it to a new frequency. Then Tagged File
> > Sink would wait for the new "rx_freq" tag to store samples (this
> way I
> > would discard the old frequency samples).
> >
> > Is this flowgraph feasible?
>
> Yes, it's possible. However, I'm not sure it'll do exactly what
> you want
> (or maybe I'm misunderstanding), for two reasons:
>
> - 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.
>
>
> - 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.
>
>
>
> Without the IIR block, do you see any problem about mixing of wanted
> and unwanted samples?
>
>
> 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?
>
>
>
>
> > In case it is, I think I only have to program my custom "Tagged File
> > Sink" with a vector data input port and a message output port. Is
> that
> > correct?
>
> Apart from what I mentioned above, yes. You might want to choose a
> different approach, e.g. an open loop approach where you simply
> send a
> retune message every N milliseconds.
>
>
>
> 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.
>
>
>
> I am open to new solutions before I program something so any tips
> are more than welcomed.
>
>
> Many many thanks.
>
>
>
>
>
> M
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hidden>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>