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?
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.
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.
- 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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.