Message Passing

GNU Radio
1

Dear gurus,

I am learning gnuradio Message Passing feature, but couldn’t get
desirable
result.
The Message seems published successfully, but not subscribed by the
Message
receiver.
How to correct the error …?

The message sender block:

// constructor
    message_source1_impl::message_source1_impl()
      : gr::sync_block("message_source1",
              gr::io_signature::make(0, 0, 0),
              gr::io_signature::make( 1, 1, sizeof(int)) )
    {
        message_port_register_out( pmt::mp("print") );
    }

    // send_message1
    void
    message_source1_impl::send_message1()
    {
        std::cout << "message_source1_impl::send_message():

invoked"
<< std::endl;
pmt::pmt_t str0 = pmt::string_to_symbol(
std::string(“Welcome
2014”));
message_port_pub( pmt::mp(“print”), str0 );
}

    // work
    int
    message_source1_impl::work(int noutput_items,
              gr_vector_const_void_star &input_items,
              gr_vector_void_star &output_items)
    {
        int *out = (int *) output_items[0];
        for (int i=0; i < noutput_items; i++)
            out[i] = (i+1) * (i+1);

        send_message1();
        return noutput_items;
    }

The message receiver block:

// constructor
    message_sink1_impl::message_sink1_impl()
      : gr::sync_block("message_sink1",
              gr::io_signature::make(0, 0, 0),
              gr::io_signature::make( 1, 1, sizeof(int)) )
    {
        message_port_register_in( pmt::mp("print") );
        set_msg_handler( pmt::mp("print"), boost::bind(

&message_sink1_impl::handler1, this, _1 ) );
}

    // message handler
    void
    message_sink1_impl::handler1( pmt::pmt_t myMessage )
    {
        std::cout << "message_sink1_impl::handler1():  invoked" <<

std::endl;
pmt::print( myMessage );
}

    // work
    int
    message_sink1_impl::work(int noutput_items,
              gr_vector_const_void_star &input_items,
              gr_vector_void_star &output_items)
    {
        int *out = (int *) output_items[0];
        for (int i=0; i < noutput_items; i++)
            out[i] = i+1;

        return noutput_items;
    }

Flow graph execution output:
Executing: “/home/mmkk/gnuradio/gr-activecat/apps/top_block.py”
message_source1_impl::send_message(): invoked
message_source1_impl::send_message(): invoked
message_source1_impl::send_message(): invoked
message_source1_impl::send_message(): invoked
message_source1_impl::send_message(): invoked

2

On 14.05.2014 08:11, Activecat wrote:

Dear gurus,

I am learning gnuradio Message Passing feature, but couldn’t get
desirable result.
The Message seems published successfully, but not subscribed by the
Message receiver.
How to correct the error …?

Just to make sure: You did connect the ports in your flow graph?

That said, I’ve seen something like this recently. Maybe there’s a
bug… needs investigating.

M

3

On Wed, May 14, 2014 at 4:26 PM, Martin B.
[email protected]wrote:

Just to make sure: You did connect the ports in your flow graph?
That said, I’ve seen something like this recently. Maybe there’s a bug…
needs investigating.
M

Both blocks (message sender block, message receiver block) are source
blocks, both are directly connected to the inputs of a divider blocks,
i.e. the message receiver block is not at the downstream of the message
sender block. I guess this is ok because Message Passing is for
downstream
blocks to communicate to upstream blocks. Is this correct?

This is part of the top_block.py generated by GRC, to illustrate the
flowgraph.

    ##################################################
    # Blocks
    ##################################################
    self.blocks_head_0 = blocks.head(gr.sizeof_int*1, 10)
    self.blocks_divide_xx_0 = blocks.divide_ii(1)
    self.activecat_message_source1_0 = activecat.message_source1()
    self.activecat_message_sink1_0 = activecat.message_sink1()
    self.activecat_integer_sink3_0 = activecat.integer_sink3(False,

True, “Integer1”)

    ##################################################
    # Connections
    ##################################################
    self.connect((self.blocks_divide_xx_0, 0), (self.blocks_head_0,

0))
self.connect((self.blocks_head_0, 0),
(self.activecat_integer_sink3_0, 0))
self.connect((self.activecat_message_source1_0, 0),
(self.blocks_divide_xx_0, 0))
self.connect((self.activecat_message_sink1_0, 0),
(self.blocks_divide_xx_0, 1))

System info:
Gnuradio version = 3.7.3
OS = Debian jessie/sid, SMP Debian 3.13.10-1 x86_64 GNU/Linux

4

On Wed, May 14, 2014 at 5:26 PM, Martin B.
[email protected]wrote:

There’s no msg_connect() call here – that would be your problem.
M

I build the flowgraph using GRC. How to make correction?
The complete top_block.py is as follows.

#!/usr/bin/env python
##################################################

Gnuradio Python Flow Graph

Title: Top Block

Generated: Wed May 14 17:30:37 2014

##################################################

from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import activecat
import wx

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
    grc_wxgui.top_block_gui.__init__(self, title="Top Block")
    _icon_path =

“/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png”
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

    ##################################################
    # Variables
    ##################################################
    self.samp_rate = samp_rate = 32000

    ##################################################
    # Blocks
    ##################################################
    self.blocks_head_0 = blocks.head(gr.sizeof_int*1, 10)
    self.blocks_divide_xx_0 = blocks.divide_ii(1)
    self.activecat_message_source1_0 = activecat.message_source1()
    self.activecat_message_sink1_0 = activecat.message_sink1()
    self.activecat_integer_sink3_0 = activecat.integer_sink3(False,

True, “Integer1”)

    ##################################################
    # Connections
    ##################################################
    self.connect((self.blocks_divide_xx_0, 0), (self.blocks_head_0,

0))
self.connect((self.blocks_head_0, 0),
(self.activecat_integer_sink3_0, 0))
self.connect((self.activecat_message_source1_0, 0),
(self.blocks_divide_xx_0, 0))
self.connect((self.activecat_message_sink1_0, 0),
(self.blocks_divide_xx_0, 1))

QT sink close method reimplementation

def get_samp_rate(self):
    return self.samp_rate

def set_samp_rate(self, samp_rate):
    self.samp_rate = samp_rate

if name == ‘main’:
import ctypes
import sys
if sys.platform.startswith(‘linux’):
try:
x11 = ctypes.cdll.LoadLibrary(‘libX11.so’)
x11.XInitThreads()
except:
print “Warning: failed to XInitThreads()”
parser = OptionParser(option_class=eng_option, usage=“%prog:
[options]”)
(options, args) = parser.parse_args()
tb = top_block()
tb.Start(True)
tb.Wait()

5

On 14.05.2014 11:14, Activecat wrote:

Both blocks (message sender block, message receiver block) are source
blocks, both are directly connected to the inputs of a divider blocks,
i.e. the message receiver block is not at the downstream of the message
sender block. I guess this is ok because Message Passing is for
downstream blocks to communicate to upstream blocks. Is this correct?

The message passing API doesn’t really care about who’s upstream for the
streaming API.

     self.activecat_integer_sink3_0 = activecat.integer_sink3(False,
     self.connect((self.activecat_message_sink1_0, 0),

(self.blocks_divide_xx_0, 1))

There’s no msg_connect() call here – that would be your problem.

M

6

On Wed, May 14, 2014 at 5:50 PM, Sylvain M. [email protected]
wrote:

Then they should show as message port in the GRC UI and you need to
connect them in the GUI.

This works: (this add additional port in gray color)

print message 1

Whereas this doesn’t work: (the block becomes disappeared in the GRC)

print
message
1

Then how to define the message sink port?

7

Hi,

There’s no msg_connect() call here – that would be your problem.
M

I build the flowgraph using GRC. How to make correction?
The complete top_block.py is as follows.

Did you define the message port in the .grc XML file for your blocks ?

Something like :

portname message 1

Then they should show as message port in the GRC UI and you need to
connect them in the GUI.

Cheers,

Sylvain

8

On 14.05.2014 11:35, Activecat wrote:

On Wed, May 14, 2014 at 5:26 PM, Martin B. <[email protected]
mailto:[email protected]> wrote:

There's no msg_connect() call here -- that would be your problem.
M

I build the flowgraph using GRC. How to make correction?

To correct this, connect the message ports.

M

9

On Wed, May 14, 2014 at 6:18 PM, Activecat [email protected] wrote:

Whereas this doesn’t work: (the block becomes disappeared in the GRC)

print
message
1

Then how to define the message sink port?

I have then tested few combinations, it seems that a source block cannot
have a message sink port.
Is there such a restriction …?

10

On 05/14/2014 12:29 PM, Activecat wrote:

I have then tested few combinations, it seems that a source block cannot
have a message sink port.
Is there such a restriction …?

Not that I know of…

<?xml version='1.0' encoding='ASCII'?> Test message_sink_complex_source_test Custom None in message True out complex

Works here (GR version: recent master).

(This is a dummy block. The generated FG wont run)

Sebastian

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Sebastian Koslowski
Research Associate

Kaiserstrae 12
Building 05.01
76131 Karlsruhe, Germany

Phone: +49 721 608-46275
Fax: +49 721 608-46071
Email: [email protected]
Web: http://www.cel.kit.edu/

KIT University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association

11

On Wed, May 14, 2014 at 7:06 AM, Activecat [email protected] wrote:

Problem solved, thank everyone !

Yes, this is the strictness of the XML DTD. Glad you got it working.

Tom

12

On Wed, May 14, 2014 at 10:25 PM, Tom R. [email protected] wrote:

Yes, this is the strictness of the XML DTD. Glad you got it working.
Tom

Thank you very much.

13

On Wed, May 14, 2014 at 6:49 PM, Koslowski, Sebastian (CEL) <
[email protected]> wrote:

message_sink_complex_source_test

I retried by putting the definition of on top of

in the xml file, it works. It seems that the "sink" definition must be placed on top of "source" ..

Problem solved, thank everyone !