# Msg passing + tag streaming: Is this flowgraph possible? **URL:** \ **Category:** GNU Radio\ **Created:** [February 20, 2015, 9:35am UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274 "2015-02-20T09:35:08Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 20, 2015, 9:35am UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/1 "2015-02-20T09:35:08Z")
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? 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? 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? Any suggestions/ideas? Thanks in advance, Jorge ---
**Author:** ![jorgegetafe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jorgegetafe](https://www.ruby-forum.com/u/jorgegetafe)\ **Post date:** [February 20, 2015, 10:28am UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/2 "2015-02-20T10:28:31Z")
On 02/20/2015 09:33 AM, Jorge G. 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. > 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. - 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. > 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. M ---
**Author:** ![jorgegetafe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jorgegetafe](https://www.ruby-forum.com/u/jorgegetafe)\ **Post date:** [February 20, 2015, 12:34pm UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/3 "2015-02-20T12:34:04Z")
On 20 February 2015 at 10:26, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > Sink or does any block in the middle get rid of them? > > Sink would wait for the new “rx\_freq” tag to store samples (this way I > > 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. ---
**Author:** ![jorgegetafe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jorgegetafe](https://www.ruby-forum.com/u/jorgegetafe)\ **Post date:** [February 23, 2015, 6:06pm UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/4 "2015-02-23T18:06:09Z")
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 ---
**Author:** ![jorgegetafe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jorgegetafe](https://www.ruby-forum.com/u/jorgegetafe)\ **Post date:** [February 23, 2015, 6:09pm UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/5 "2015-02-23T18:09:15Z")
On 02/20/2015 12:32 PM, Jorge G. 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 ---
**Author:** ![jorgegetafe](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/eada6e/32.png) [@jorgegetafe](https://www.ruby-forum.com/u/jorgegetafe)\ **Post date:** [February 23, 2015, 9:02am UTC](https://www.ruby-forum.com/t/msg-passing-tag-streaming-is-this-flowgraph-possible/234274/6 "2015-02-23T09:02:24Z")
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_msg_passing.html) [http://gnuradio.org/doc/doxygen/page\_stream\_tags.html](http://gnuradio.org/doc/doxygen/page_stream_tags.html) [http://gnuradio.org/doc/doxygen/page\_tagged\_stream\_blocks.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.