Hier_block2 syntax question

GNU Radio
1

hi all-

Quick question about syntax for connecting components inside a
hier_block2…

Let A = hier_block2’s input

Let’s say I want a mult inside that multiplies A and a delayed version
of A
together.

    self.delay = gr.delay(gr.sizeof_gr_complex,

2*self._samples_per_symbol) #2T delay
self.mult = gr.multiply_cc()

    self.connect(self, self.delay, (self.mult, 0))
    self.connect(self, (self.mult, 1))
    self.connect(self.mult, [other stuff here], self)

gives me:
ValueError: external input port 0 already wired to delay(12):0

What am I doing wrong? What is the correct syntax?

2

Steven C. wrote:

What am I doing wrong? What is the correct syntax?

The good news is that you are doing the right thing for what you want to
accomplish.

The bad news it that it isn’t supported (yet) :slight_smile:

The ability to wire a hier_block2 external input to multiple internal
gr-block inputs is reasonable but wasn’t implemented in the current
code.

Track ticket 161 is open to fix this; we’ll either do this before the
3.1 stable release or as part of the 3.1 series. When it is
implemented, it work exactly as you have written your code.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

3

Ok, thanks Johnathan. Can we fake it in the meantime by throwing in a
“nop”
block?
self.nop = gr.nop(gr.sizeof_gr_complex)
self.delay = gr.delay(gr.sizeof_gr_complex,
2*self._samples_per_symbol) #2T delay
self.mult = gr.multiply_cc()

    self.connect(self, self.nop, self.delay, (self.mult, 0))
    self.connect(self.nop, (self.mult, 1))
    self.connect(self.mult, [other stuff here], self)

This runs without complaint, but doesn’t seem like any data is getting
through…

4

Steven C. wrote:

This runs without complaint, but doesn’t seem like any data is getting
through…

Try a gr.kludge_copy or gr.skiphead(0)

5

Steven C. wrote:

Ok, thanks Johnathan. Can we fake it in the meantime by throwing in a
“nop” block?

gr.nop doesn’t copy from input to output; you want gr.kludge_copy or
gr.skiphead(0).

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

6

Johnathan C. wrote:

Steven C. wrote:

Ok, thanks Johnathan. Can we fake it in the meantime by throwing in a
“nop” block?

gr.nop doesn’t copy from input to output; you want gr.kludge_copy or
gr.skiphead(0).

I ran into the same problem as the original poster a little while ago.
I’m trying to convert the OFDM blocks to hier2, and testing the new
hier2 TX path I wrote with the old hier RX path worked fine. The RX part
of OFDM is a bit more complicated, with more areas that the input is
connected to various blocks. I was using the old gr.add_const_cc(0) to
split the input but all the blocks after it seemed to receive no data
(according to the logging on ofdm_sync_pnac and ofdm_receiever).

Using gr.kludge_copy or skiphead seems to have the same problem, so I
moved up in the hierarchy to the ofdm.ofdm_demod block. There I changed:

     self.connect(self, self.ofdm_recv)

     self.connect((self.ofdm_recv, 0), (self.ofdm_demod, 0))
     self.connect((self.ofdm_recv, 1), (self.ofdm_demod, 1))

to:

     self.kludge = gr.kludge_copy(gr.sizeof_gr_complex)
     self.connect(self, self.kludge)

     self.connect(self.kludge, gr.file_sink(gr.sizeof_gr_complex,

“ofdm_kludge.dat”))

     self.connect(self.kludge, self.ofdm_recv)
     self.connect((self.ofdm_recv, 0), (self.ofdm_demod, 0))
     self.connect((self.ofdm_recv, 1), (self.ofdm_demod, 1))

To try and log what’s getting passed into ofdm_recv. However running the
changed version produces:

terminate called after throwing an instance of ‘std::runtime_error’
what(): fft_filter_ccc(5): insufficient connected input ports (2
needed, 1 connected

The first block in ofdm_recv is this fft_filter_ccc, and it is connected
directly from the input of the hier2 block. Changing back to the
previous version of the code does not produce this error, but no data
reaches the logging functions in ofdm_receiver. The .cc file of
fft_filter_ccc seems to show that it only takes one input, so I’m
confused as to why I’m receiving that error.

If anyone is interested, I’ve uploaded my current progress to
http://155.246.68.205/filebin/ofdmblks2.tar.gz

The benchmark_tx/rx files have been modified to use the local copies of
the ofdm blocks, so it can be run in place.

Thanks!
Dev