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 <jmig...@gmail.com> wrote: > > On 20 February 2015 at 10:26, Martin Braun <martin.br...@ettus.com> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
