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

Reply via email to