Usage of Message Queues

GNU Radio
1

Hello!
I have another question, this time about message queues. I have a
demodulator hooked up to message sink. But when I want to pop a message
via
tb.sink_queue.delete_head(), its just returning that to me:

<gnuradio.gr.gnuradio_core_runtime.gr_message_sptr; proxy of <Swig
Object
of type ‘gr_message_sptr *’ at 0xae276b0> >

I dont know so much about Python and GnuRadio, but it looks like a
Pointer
of that SWIG for me. How can I get the value?
Thanks in advance

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

Im sorry that im pushing my question, but its still unsolved for me and
need
it for my project…

So again, my message queue is filling, i checked that via
tb.sink_queue.count(), but if i want to transfer pop a message, it just
returns me that message_sptr thing. Can someone help me on that? I cant
find
a proper manual how to use the message queues/sinks.

Again, thanks in advance for any hints :).

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39455.html
Sent from the GnuRadio mailing list archive at Nabble.com.

3

Again, thanks in advance for any hints :).

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39455.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi,

I don’t know much about messages and it’s queues from the python side,
but
maybe a hint to the C++ side will help you to continue.

It appears that the object you get back is a wrapped shared pointer. So
basically a pointer to a gr_message which’s C++ interface is documented
here: http://gnuradio.org/doc/doxygen/classgr__message.html
In C++ you can use the shared pointer like a usual pointer to that class
so I guess that’s the same in gnuradio. Just try if you can get the
length
of the message with returned_var.length()
Usually with the msg() member you return an unsigned char pointer to the
actual data of the message. My best guess would be that this is wrapped
to
a list of numpy’s uint8 values.

I hope that makes it possible for you to continue. Another possible
source
might be the QA code for gr_msg_source and gr_msg_sink (if there is any)
which should deal with messages in python.

Yours
Martin

4

Thank you much for your answer. Indeed, its a shared pointer. I now
figured
out, the the only way to get the data is via .to_string(). Though, im
stuck
again. I use the following code to initialize the queue and message
sink:

self.sink_queue = gr.msg_queue()
self.gr_file_source_0 = gr.file_source(gr.sizeof_char*1, "stream",

False)
self.gr_message_sink_0 = gr.message_sink(gr.sizeof_char*1,
self.sink_queue, False)

Then I’m putting a DPSK mod and demod between and connect the output of
the
demod to the message sink:

self.connect((self.gr_file_source_0, 0), (self.gr_throttle_0, 0))
self.connect((self.gr_throttle_0, 0), (self.digital_dxpsk_mod_0, 0))
self.connect((self.digital_dxpsk_mod_0, 0),

(self.digital_dxpsk_demod_0,
0))
self.connect((self.digital_dxpsk_demod_0, 0),
(self.gr_message_sink_0, 0))

So my thought was, that all the messages then should contain one byte
(with
one bit information). At the end, my code looks like that:

tb = top_block()
tb.start()

while 1:

  point=tb.sink_queue.delete_head()
  point=point.to_string()
  print len(point)

The first curiosity is, that the length variates from 2 up to 2048. Can
somebody explain why? The next question is, how to i convert the
“bitvalue”
of the string to an actual char?

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39815.html
Sent from the GnuRadio mailing list archive at Nabble.com.

5

Thank you again for your answer. I looked up the Header File of
gr_message
and it should have the msg() attribute. But when I tried to access, it
gave
me the error that this attribute isnt existing.
Anyway, I now figured out a way which is enough for me: I converted the
returned string to a list of bits, and then conert them to a list of
bytes,
This gives me back the wanted output stream of the demodulator.

–
View this message in context:
http://gnuradio.4.n7.nabble.com/Usage-of-Message-Queues-tp39295p39893.html
Sent from the GnuRadio mailing list archive at Nabble.com.

6

Am 23.02.2013 17:09, schrieb Hanz:

Thank you much for your answer. Indeed, its a shared pointer. I now figured
out, the the only way to get the data is via .to_string().

  print len(point)

The first curiosity is, that the length variates from 2 up to 2048. Can
somebody explain why? The next question is, how to i convert the “bitvalue”
of the string to an actual char?

Hi,

your code setup with the blocks and connects looks fine to me.

Although I have not checked the details of msg_sink I would expect it to
process blocks of incomming bytes into messages. So a message can
contain an abritrary amount of bytes in it (I think that is why your
length varies). Once again speaking for the C++ interface with the
method length() you will get the number of elements that this message
contains. Then you can usually access the message’s data through a call
to the msg() function which returns a pointer to a byte array containing
the bytes. This will be wrapped to some python code, so check the return
type of msg() and try to process this returned data instead of
to_string() if you are interested in the data itself. So I think your
code should look something like this (not tested, please check agains
the actual Python interface documented with Sphinx or Python
docstrings):

message=tb.sink_queue.delete_head()
data=message.msg()
length=message.length()

for i in xrange(length) :
byte=data[i]

Hope this gives you an idea on how to use the interface.

Martin