Re: function probes don't work in hierarchical blocks

Hi Eugene, agreed, that's a bit ugly. Unless someone comes up with a very non-intrusive and prettier solution, I'll propose we'll leave it as is: Function Probes are an ugly hack, that has, over the course of time, caused more harm than good. If you need to probe a signal at regular intervals from a sample stream¹, you should probably properly decimate (i.e., low-pass filter with decimation >> 1) or just keep 1-in-N instead. If you really need "random times relative to sample processing, but time controlled by the asynchronous reality of the computer around it", then sending messages into a python block's "trigger" input message port, and that block then sending a (sample index, value) tuple out a "value" message port would solve the same issue, but in a way that's compatible with hier blocks. (subliminal message here: don't rely on function probes. I have not *once* found a good use case for them.) Best regards, Marcus ¹ don't forget that GNU Radio blocks always process samples in larger chunks, so "wall-clock time" has, at best, usually not at all, a very loose relation to signal being probed On 2026-07-21 6:40 PM, Eugene Grayver wrote: > Functions probes don't work in hierarchical blocks. > A function probe generates a thread body such as: > > ------- >         def _cross_freq_estimate_probe(): >           self.flowgraph_started.wait() >           while True: > >             val = self.cross_freq_probe.level() > ------- > > However, hierarchical blocks don't have a member flowgraph_started.  I don't have a simple > suggestion, but perhaps we can pass this member from the parent?  A bit ugly!  Makes the > hier blocks dependent on the rest of the GRC framework — i.e. can't easily reuse in > python-only design flow. > > > Eugene Grayver, Ph.D. > Principal Engineer > 310-336-1274

Re: GRC file sink/source name does not honor variables

Re: GRC file sink/source name does not honor variables

On 2026-07-21 12:58, Eugene Grayver wrote:

The GRC file sink/source filename does not support variable expansion.  Is this an intentional decision or a bug?

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

I've used full-on python expressions in there in the past, so, if that's no longer working, it's a bug.

GRC file sink/source name does not honor variables

The GRC file sink/source filename does not support variable expansion.  Is this an intentional decision or a bug?

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

Function probe block id

Function probe block id checks for a valid Python variable name.  However, it should allow a block.sub_block notation to support accessing blocks inside hierarchical blocks.  This would be a trivial change.

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

function probes don't work in hierarchical blocks

Functions probes don't work in hierarchical blocks. 

A function probe generates a thread body such as:

-------

        def _cross_freq_estimate_probe():

          self.flowgraph_started.wait()

          while True:

            val = self.cross_freq_probe.level()

-------

However, hierarchical blocks don't have a member flowgraph_started.  I don't have a simple suggestion, but perhaps we can pass this member from the parent?  A bit ugly!  Makes the hier blocks dependent on the rest of the GRC framework — i.e. can't easily reuse in python-only design flow.

Eugene Grayver, Ph.D.

Principal Engineer

310-336-1274

Re: code snippet in hierarchical block

Hey Eugene, Thanks for pointing that out! I converted that to an issue report, so we don't lose track of it: https://github.com/gnuradio/gnuradio/issues/8163 Best regards, Marcus On 2026-07-17 12:49 AM, Eugene Grayver wrote: > Code snippet 'Main - After Init' does not work in hierarchical blocks.  The functions are > correctly created at the top of the file *but are never called* in the code body.  This > seems like a simple issue to fix (sorry I can't contribute). > > Eugene Grayver, Ph.D. > Principal Engineer > 310-336-1274