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