Hey all,
Using benchmark_qt_loopback2.py as a starting point, I’m receiving
digital
data from an external sensor using my own RF front end. The data is
being
received correctly, but my problem is this. I’d like to plot the
received
data in real-time (not the received signal) every time a correct data
packet
is received. The problem is really just how to pass the data from one
sink
to another source.
My last receive chain signal processing block is gr_framer_sink1. This
returns the payload with the crc which is passed up to a higher layer
where
a crc check is performed. Finally, the payload is passed to my top
layer.
Since this is a sink function, it doesn’t pass its data to another
block. I
could modify it to do this, but I require some of the higher level
functions
to verify the payload. I’ve tried to use a vector_source and append the
data
to it every time a correct packet is received and then attach that
source to
my plot sink, but this does not work. The vector is correctly modified,
but
this data is not passed to the plot. There’s also the problem then of
only
updating when the packet is received.
I realize that my method may not be the most efficient, so if you know
of a
better way to accomplish this, I’d very much appreciate it.
Thanks for your help in advance!
View this message in context:
http://old.nabble.com/Plotting-Data-Received-by-USRP-tp32126980p32126980.html
Sent from the GnuRadio mailing list archive at Nabble.com.
to verify the payload. I’ve tried to use a vector_source and append the data
to it every time a correct packet is received and then attach that source to
my plot sink, but this does not work. The vector is correctly modified, but
this data is not passed to the plot. There’s also the problem then of only
updating when the packet is received.
The message source and message sink blocks are great ways to get data
into and out-of a stream. -josh
That’s what i’m doing now. The vector_source i’m using is correctly
updating
itself if I check the value, but it seems that the updated vector_source
isn’t being passed to the plotter_sink (when I connect the source to the
plotter sink).
Josh B.-2 wrote:
updating when the packet is received.
–
View this message in context:
http://old.nabble.com/Plotting-Data-Received-by-USRP-tp32126980p32128941.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Ok, I wasn’t aware of those difference between the vector source and the
message source. So if I put my data in a message source, can I connect
this
directly to qtgui.time_sink_f? I’d think I’d have to do some other
formatting here.
Let me explain a bit more…after receiving the payload from the message
sink following the receiver path in benchmark_rx, I have some data. I’d
like
to plot this data on a time graph and update it after every packet is
received. I guess fundamentally my question is, what type of source do I
need to do this. It appears that a message source is the wrong length to
connect to the time_sink_f.
Tom R. wrote:
source to listen for the messages and process them farther from there.
Tom
–
View this message in context:
http://old.nabble.com/Plotting-Data-Received-by-USRP-tp32126980p32150867.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Wed, Jul 27, 2011 at 3:29 PM, valentac [email protected]
wrote:
need to do this. It appears that a message source is the wrong length to
connect to the time_sink_f.
As I said, you’ll have to look more at some of the examples that use
the message sources and sinks to understand how to handle this. You’ll
eventually set up a second flow graph with a message source and
graphical sink. Your receiver flow graph will then send the messages
from itself to the message source. How this is actually implemented is
“left as an exercise to the reader.”
Tom
On Sun, Jul 24, 2011 at 11:57 PM, valentac [email protected]
wrote:
That’s what i’m doing now. The vector_source i’m using is correctly
updating
itself if I check the value, but it seems that the updated vector_source
isn’t being passed to the plotter_sink (when I connect the source to the
plotter sink).
Josh suggested the use of message source/sink, not the vector
source/sinks
that you are currently using. Two different things. The vector source
and
sink are meant more for testing and debugging while the message source
and
sink are designed to handle exactly your situation in a running program.
Look through the benchmark_rx code we have. The framer at the end of the
receive chain is a message sink, actually, and we get the messages in a
callback function in the Python world. You would have to set up a
message
source to listen for the messages and process them farther from there.
Tom