Also known as: hier block, hierarchical block
A hierarchical block is a sub-flowgraph packaged so that it looks and behaves like a single block.1 Internally it is several blocks wired together; externally it exposes just input and output ports, so the rest of a design can drop it in as one node and never see its innards. Hierarchical blocks are how block-based SDR scales: they let you name a chunk of processing (“FM receiver,” “P25 demod front end”), reuse it, and nest it, so a large radio stays a readable handful of high-level boxes instead of a wall of hundreds of primitive blocks.
How it works
A hierarchical block defines its own input and output signatures, then wires internal blocks between special self ports that stand for the block’s own boundary. Connecting an internal block to the hier block’s input port routes the composite’s incoming samples into it; connecting to the output port routes results back out. Once defined, the hier block is a first-class node: you connect it into a parent flowgraph exactly like any primitive block, and the scheduler flattens the hierarchy — it schedules the internal blocks directly, so nesting is a source-level convenience with no runtime penalty from the boxing itself.
The interface is the point. By exposing only ports and a few construction parameters (a center frequency, a decimation factor), the hier block hides its internal wiring the way a function hides its body. This is ordinary abstraction: callers depend on the signature, not the implementation, so you can rework the internals — swap the demodulator, add an AGC — without touching anything that uses the block.
In practice
Hierarchical blocks are created two ways that produce the same thing. In GNU Radio Companion you build a flowgraph whose source and sink are “pad” blocks; GRC generates a reusable hier block from it that then appears in your block library. In code you subclass the hier-block base type, declare the io signatures in the constructor, and connect the internals. Either way the result can be published in an out-of-tree module and shared like any other block.
Good hier blocks are cohesive — one clear job, a small parameter list, clean port types — for the same reasons good functions are. A hier block that reaches into global state or needs a dozen tightly-coupled parameters is a sign the boundary was drawn in the wrong place.
Relevance to SDR
Composition is what keeps real receivers maintainable. A production decoder is dozens of primitive stages; without a way to group them, the top-level flowgraph becomes unreadable and nothing is reusable. Hier blocks give SDR the same modularity that functions and modules give general software — build once, name it, reuse it, nest it — and they make it practical to ship libraries of ready-made radio front ends.
GopherTrunk is pure Go and does not use GNU Radio’s
hier_block2, but it applies the identical principle through Go packages and types: the
down-conversion front end, the C4FM demodulator, and each protocol decoder are self-contained
units with narrow interfaces that a higher layer composes into a full scanner, hiding their
internals behind a handful of exported methods. Whether the mechanism is a GNU Radio hier block
or a Go package, the goal is the same — express a complex radio as a small number of
well-named, reusable pieces rather than one flat mass of DSP.
Sources
-
Hierarchical Blocks — GNU Radio Wiki, on composing sub-flowgraphs into reusable blocks with their own io signatures and pad ports. ↩