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
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.
> Im sorry that im pushing my question, but its still unsolved for me and
> 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
> 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.
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.
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:
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().
> 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()
> while 1:
> 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?
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):
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.