# GRC Message Source/Sink and Packet Source

**URL:** <https://www.ruby-forum.com/t/grc-message-source-sink-and-packet-source/220290>\
**Category:** GNU Radio\
**Created:** [June 5, 2012, 12:18pm UTC](https://www.ruby-forum.com/t/grc-message-source-sink-and-packet-source/220290 "2012-06-05T12:18:47Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gurdipe\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b77776/32.png) [@Gurdipe\_D](https://www.ruby-forum.com/u/Gurdipe_D)\
**Post date:** [June 5, 2012, 12:18pm UTC](https://www.ruby-forum.com/t/grc-message-source-sink-and-packet-source/220290/1 "2012-06-05T12:18:47Z")

</div>

Hi!

I’m trying to integrate an existing Packet Source into GRC. I have  
some trouble understanding how this is supposed to work:

In order to send a packet I need to use the gr\_message\_queue. How do I  
call a function to add a message to a queue from GRC?

My Packet Source is supposed to define a message. A Message Sink takes  
one input. I connect that input with a Message Source. I understand  
that in this case the Sink accepts data.  
A packet is a byte data structure. So I want to send bytes to Message  
Sink. How can I return a byte structure into the message sink now? Is  
there any code that does that with GRC block? I know that  
transmit\_path.py or benchmark\_tx.py do that, but they are not  
separated. Therefore it’s by far simpler here.

Best,  
Marius

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [June 5, 2012, 6:34pm UTC](https://www.ruby-forum.com/t/grc-message-source-sink-and-packet-source/220290/2 "2012-06-05T18:34:02Z")

</div>

On 06/05/2012 03:17 AM, Marius wrote:

> Hi!
> 
> I’m trying to integrate an existing Packet Source into GRC. I have  
> some trouble understanding how this is supposed to work:

Actually, this packet sink is integrated into GRC and the design is  
actually as regrettable as you can imagine:

[http://gnuradio.org/cgit/gnuradio.git/tree/grc/grc\_gnuradio/blks2/packet.py](http://gnuradio.org/cgit/gnuradio.git/tree/grc/grc_gnuradio/blks2/packet.py)

[http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2\_packet\_encoder.xml](http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2_packet_encoder.xml)

[http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2\_packet\_decoder.xml](http://gnuradio.org/cgit/gnuradio.git/tree/grc/blocks/blks2_packet_decoder.xml)

The blocks have stream IO all the way, which means there is code slicing  
up the stream and feeding the message queue; yes, and spitting it back  
out to stream for the decoder.

It probably would be better to have offered a message queue as the input  
or output, but these were written before GRC supported message queues.

I also created a version of this packet framer/deframer which uses the  
PMT message passing feature instead, there is a nice screenshot in the  
message section: [Home · guruofquality/grextras Wiki · GitHub](https://github.com/guruofquality/grextras/wiki)

-josh