discuss-gnuradio
[Top][All Lists]
Advanced

[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
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]