Usage of Message Queues

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.

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.

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

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.

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.

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs