> ....
> arr = numpy.array(random.random(), numpy.float32)
> return gr.message_from_string(arr.tostring(), 0, gr.sizeof_float, 1)
> self._msgq.insert_tail(msg)
> ....
>
From the doxygen:
gr_message_sptr gr_make_message_from_string (const std::string s, long
type, double arg1, double arg2)
A message is just a string of bytes, and them some arguments. The
arguments are implementation dependent. In the grc code, those arguments
are not even used, probably copy-pasted from some other code.
Basically, you put binary data into a message, which goes into a message
queue, and then its up to whoever reads from the queue to cast this data
into the correct form.
As a side note: Some of that grc/message passing kludgery needs to be
revisited. But I would hesitate to do so because that PMT work may come
to fruition...
> I'm not entirely clear about the argument structure for gr.message_from_string() function, for which I couldn't find much documentation. I could understand the second argument represents message type (0 for all data messages, 1 for End-Of-Message). I've no idea what the third and fourth argument actually conveys.
>
> I do understand that message queues were not exactly built for this purpose. But I'm sure the mechanism to make the data acceptable to the traditional Sink blocks would have some good use, let alone this poor chap's ;)
>
> Or am I in the wrong direction using message queues ?
>
Message source and sinks are designed to get data in and out of gnuradio
streams. Message queues and messages are how you interface with a
message source or sink; by putting or taking messages in and out of a queue.
Internally in the gr-wxgui stuff, all the blocks actually use message
sinks to take streaming data out of gnuradio and get it into python for
plotting.
If you are having issues with the plotters, make sure that the samples
rates match up, that can cause issues because the plotters try to
decimate to achieve frame rate. Also be aware that the gr runtime passes
around bit chunks of memory at a time, not single numbers, so you may be
seeing an artifact of that.
-josh
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment