This is for a version of gnuradio from git on May 24, 2019.
If I connect my block to a qtgui time sink in grc it grc displays the
input port as "in0" but the time_sink_c_impl.cc code declares the
message port as "in," causing execution of the flowgraph to fail.
I've found two short term options: 1. modify time_sink_c_impl.cc to
accept "in0" as:
// setup PDU handling input port
// message_port_register_in(pmt::mp("in"));
// set_msg_handler(pmt::mp("in"),
// boost::bind(&time_sink_c_impl::handle_pdus,
this, _1));
message_port_register_in(pmt::mp("in0"));
set_msg_handler(pmt::mp("in0"),
boost::bind(&time_sink_c_impl::handle_pdus, this,
_1));
I suspect that this will break things if I add more input ports.
Option 2: Modify the python code that grc generates
self.msg_connect((self.dave_specsplit_0, 'AngleVsFreq'
(self.qtgui_time_sink_x_0_0, 'in0'))
to:
self.msg_connect((self.dave_specsplit_0, 'AngleVsFreq')
(self.qtgui_time_sink_x_0_0, 'in'))
This isn't a great solution since it has to be done every time the flow
graph changes. I suspect that a better solution would be to get grc to
make flow graphs that understand the input port name. I just want
through the process of porting my OOT modules from xml to yml and don't
have this problem because I specified the port names explicitly with
the "-label" field. I looked at doing this with the qt gui blocks but
they're using $variables beyond my yml skills.
Am I missing something in making my flowgraphs, or is this just a case
of imperfect automated xml-yml porting that will get corrected soon.
Tnx!
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
